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Introduction 



Zi log's name has become synonomous with logic 
innovation and advanced microprocessor architec- 

TM 

ture since the introduction of the Z80 m CPU in 
1973. The Zilog Family of microprocessors and 
microcomputers has grown to include the products 
listed in the table below. Each product exhibits 
special features that make it stand above similar 
products in the semiconductor marketplace. These 
special features have proven to be of substantial 
aid in the solution of microprocessor design 
problems. 

This reference book contains a collection of 
application information about Zilog microprocessor 
products. It includes technical articles, appli- 
cation notes, concept papers, and benchmarks. The 
reference book is intended as the first of several 
such volumes. We at Zilog believe that designing 
innovative microprocessor integrated circuit 



products is only half the key that unlocks the 
future of microprocessor-based end products: the 
other half is the creative application of those 
products. Advanced microprocessor products and 
their creative application lead to end product 
designs with more features, more simply imple- 
mented, at a lower system cost. It is hoped this 
reference book will stimulate new product design 
ideas as well as fresh approaches to the design of 
traditional microprocessor-based products. 

The material in this book is believed to be 
accurate and up-to-date. If you do find errors, 
or would like to offer suggestions for future 
application notes, we would appreciate hearing 
from you. Correction inputs should be directed to 
Components Division Technical Publications, and 
application suggestions should be directed to 
Components Division Application Engineering. 
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INTRODUCTION 

The semiconductor industry accomplished 
dramatic technological advances in the area of 
MOS integrated circuit microprocessors during 
the 1970' s, and as the next decade begins two 
trends are very clear. The first is the con- 
tinued increased capability of the high- end 
general purpose microprocessors. Sixteen bit 
microprocessors will mature with additional 
"big machine" features, and 32-bit microprocess- 
ors will develop. 

The second trend is in the area of single 
chip microcomputers. Single chip microcomput- 
ers are offering substantially greater process- 
ing power than when they were first introduced. 
Microcomputers are no longer limited to low end 
applications where unit cost and power dissipa- 
tion are the primary design considerations. 

Zilog is applying classical computer archi- 
tecture concepts to the design of its microcom- 
puter products. Upon close examination of the 
Zilog Z8 Microcomputer, one notices features 
that once were available only on general purpose 
bus oriented microprocessor products such as; 

• separate program and data space 

I the stack pointer and the PUSH 
and POP instructions 

t 126K byte total memory address 
space 

• vectored interrupts 

• the CALL and RET (Return) instruc- 
ions for procedure calls. 

The trend in high-end single chip microcomputer 
architecture is clear and the consequences are 
obvious. The multi-chip solutions of today that 
employ 8 -bit general purpose microprocessors 
will be replaced by more powerful 8-bit or 16- 
bit single chip microcomputers in the future. 

This paper will discuss the architectural 
features ot the Z8 Microcomputer and describe 
an application of the Z8 that takes advantage 
of the off chip expansion capability. 
ARCHITECTURAL OVERVIEW 

The architecture ot the Z8 microcomputer 
offers many advanced processing features not 
previously available with single chip microcom- 



puters. Tne Z8 combines a powertul instruction 
set, simplified system expansion oft chip, and 
tlexible serial and parallel I/O capabilities 
to provide design solutions for a wide range of 
application problems. 

The Z8 has a 16 -bit Program Counter and a 
separate 16-bit Stack Pointer. The memory space 
may be extended beyond the 2K bytes of ROM and 
124 bytes ot RAM on chip, up to 126K bytes of 
program and data memory. There are 32 bits of 
I/O which can be configured into a variety ot 
bit, nibble, and byte organizations, and the 
serial I/O port is a complete full duplex asyn- 
chronous receiver/ transmitter. Tne Z8 inter- 
rupt structure allows the user to mask and pri- 
oritize the interrupt functions under program 
control, and the interrupts are directed to the 
appropriate service routine through 16 -bit 
vectors in tne first 12 locations of program 
memory. Two counter/timers are provided to off 
load time base generation and interval detect- 
ion tasks from the Z8. Tne Z8 will operate with 
an 8 MHz clock and the exact frequency up to 8 
MHz may be set with an external crystal, an 
external RC, or an external clock source . The 
Z8 operates from a single 5 volt power supply 
and offers a power down mode that allows the 
124 general purpose registers on chip to oper- 
ate from a back up battery. A Block Diagram of 
the Z8 is given in Figure 1. 
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MEMORY SPACE AND REGISTER 

ORGANIZATION 

Memory Space 

The Z8 can address up to 126K bytes of 
program and data memory separately from the on 
chip registers. The 16-bit program counter 
provides for 64K bytes of program memory, the 
first 2K bytes of which are internal to the Z8. 
The remaining 62K bytes of program memory are 
located externally and can be implemented with 
ROM, EPROM, or RAM. 

The 62K bytes of data memory are also loc- 
ated external to tne Z8 and begin with location 
2048. The two address spaces, program memory 
and data memory, are individually selected by 
the Data Memory Select output (EM) which is 
available from Port 3. 

The Program Memory Map and the Data Memory 
Map are shown in Figure 2. 
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Figure 2 Program Memory Map And Data Memory Map 



line 4 of tne Port 3 (P34) to select between 
program and data memory for external memory oper- 
ations . 

Port is used to provide the additional 
address bits for external memory beyond the 
first 256 locations up to a full 16-bits of 
external memory address. It becomes immediately 
obvious that the first 8 -bits of external memory 
address from Port 1 must be latched externally 
to the Z8 so that program or data may be trans- 
ferred over the same 8 lines during the external 
memory transaction machine cycle. The A£, T53", 
and R/W control lines simplify the required 
interface logic. The timing for external memory 
transactions is given in Figure 3. 

Registers 

The Z8 has 144 8 -bit registers including 
four Port registers (RO-R3), 124 general purpose 
registers (R4-R127), and 16 control and status 
register (R240-R255). The 144 registers are all 
located in the same 8-bit address space to allow 
any Z8 instruction to operate on them. The 124 
general purpose registers can function as accum- 
ulators, address pointers, or index registers. 
The registers are read when they are referenced 
as source registers, and written when they are 
referenced as destination registers. Registers 
may be addressed directly with an 8 -bit address, 
or indirectly through another register with an 
8-bit address, or with a 4-bit address and Reg- 
ister Pointer. 

The entire Z8 register space may be divided 
into 16 contiguous Working Register Areas, each 
having 16 registers. A control register, called 
the Register Pointer, may be loaded with the 
most significant nibble of a Working Register 
Area address. The Register Pointer provides for 
the selection of the Working Register Area, and 
allows registers within that area to be selected 
with a 4-bit address. 

The Z8 register organization is shown in 
Figure 4. 

Stacks 



External memory access is accomplished by 
the Z8 tnrough its I/O Ports. When less than 
256 bytes of external memory are required, Port 
1 is programmed for the multiplexed address/data 
mode (AD0-AD7J. In this configuration 8-bits of 
address and 8-bits of data are time multiplexed 
on the 8 1/0 lines for memory transfers. Tne 
memory "nandshake" control lines are provided by 
tne Address Strobe (£5) , Data Strobe (E5) , and 
the Read/Write (R/W) pins on tne Z8. If program 
and data are included in the external memory 
space, the Data Memory Select (TO) function may 
be programmed into the Port 3 Mode register. 
When this is done, the TO signal is available on 



The Z8 provides for stack operations 
through the use of a stack pointer, and the 
stack may be located in the internal register 
space or in the external data memory space. The 
"stack selection 1 ' bit (D2) in the Port 0-1 Mode 
control register selects an internal or external 
stack. When the stack is located internally, 
register 255 contains an 8 -bit stack pointer and 
register 254 is available as a general purpose 
register. If an external stack is used, register 
255 or registers 254 and 255 may be used as tne 
stack pointer depending on the anticipated 
"depth" of the stack. When registers 254 and 
255 are both used, the stack pointer is a full 
16-bits wide. The CALL, IRET, RET, PUSH, and 
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External Memory Transaction Cycle 
Figure 3 
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Figure 4 Register File Organization 



POP instructions are Z8 instructions which in- 
clude iinplicit stack operations. 



I/O STRUCTURE 



Parallel I/O 



The Z8 microcomputer has 32 lines of I/O 
arranged as four 8-bit ports. All of the I/O 
ports are TTL compatible and are configurable as 
input, output, input/output, or address/data. 
The handshake control lines for Ports 0, 1, and 
2 are bits from Port 3 that have been programmed 
through a Mode control register, except for 7S", 
BS", and R/W which are available as separate Z8 
pins. The I/O ports are accessed as separate 
internal registers by tne Z8. Ports and 1 
share one Mode control register, and Ports 2 
and 3 each have a Mode control register for 
configuring the port. 

Port can be programmed to be an I/O port 
or as an address output port. More specifically 
Port can be configured to be an 8-bit I/O port, 
or a 4-bit address output port (A8-A11) for 
external memory and one 4 -bit I/O port, or an 
8-bit address output port (A8-A15) for external 
memory. 

Port 1 can be programmed as an I/O port 
(with or without handshake) , or an address/data 
port (AD0-AD7) for interfacing with external 
memory. If Port 1 is programmed to be an add- 
ress/data port, it cannot be accessed as a reg- 
ister. 

Port 2 can be configured as individual 
input or output bits, and Port 3 can be program- 
med to be parallel I/O bits, and/or serial I/O 
bits, and/or handshake control lines for the 
other ports. Figure 5 shows the port Mode 
registers . 

The off chip expansion capability using 
Ports and 1 offers the added feature of being 
Z-Bus compatible. All Z-Bus compatible peri- 
pheral chips that are available now, and will be 
available in the future, will interface directly 
with the Z8 multiplexed address/data bus. 

Serial I/O 



As memtioned in the last section, Port 3 
can be programmed to be a serial I/O port with 
bits and 7, the serial input and serial out- 
put lines respectively. The serial I/O capabil- 
ity provides for full duplex asynchronous serial 
data at rates up to 62. 5K bits per second. The 
transmitted format is one start bit, eight data 
bits including odd parity (if parity is enab- 
led), and two stop bits. The received data 
format is one start bit, eight data bits and at 
least one stop bit. If parity is enabled, the 
eighth data bit received (bit 7) is replaced by 



a parity error flag which indicates a parity 
error if it is set to a ONE. 

Timer/Counter T Q is the baud rate generator 
and runs at 16 times the serial data bit rate. 
The receiver is double duffered and an internal 
interrupt (IRQ3) is generated when a character 
is loaded into the receive buffer register. A 
different internal interrupt (IRQ4) is generated 
when a character is transmitted. 

COUNTER/TIMERS 

The Z8 has two 8-bit programmable counter/ 
timers, each of which is driven by a program- 
mable 6 -bit prescaler. The T, prescaler can be 
driven by internal or external clock sources, 
and the T Q prescaler is driven by the internal 
clock only. TTie two prescalers and the two 
counters are loaded through four control regis- 
ters (see Figure 4) and when a counter/ timer 
reaches the "end of count" a timer interrupt is 
generated (IRQ4 for T Q , and IRQ5 for T,). The 
counter/ timers can be programmed to stop upon 
reaching the end of count, or to reload and 
continue counting. Since either counter (one at 
a time) can have its output available external 
to the Z8 , and Counter/Timer T i can have an 
external input, the two counters can be cas- 
caded. 

Port 3 can be programmed to provide timer 
outputs for external time base generation or 
trigger pulses. 

INTERRUPT STRUCTURE 

The Z8 provides for six interrupts from 
eight different sources including four Port 3 
lines (P30-P33), serial in, serial out, and two 
counter/ timers. These interrupts can be masked 
and prioritized using the Interrupt Mask Regis- 
ter (register 251) and the Interrupt Priority 
Register (register 249). All interrupts can be 
disabled with the master interrupt enable bit 
in the Interrupt Mask Register. 

Each of the six interrupts has a 16 -bit 
interrupt vector that points to its interrupt 
service routine. These six 2-byte vectors are 
placed in the first twelve locations in the pro- 
gram memory space (see Figure 2) . 

When simultaneous interrupts occur for 
enabled interrupt sources, the Interrupt Prior- 
ity Register determines which interrupt is ser- 
viced first. The priority is programmable in a 
way that Is described by Figure 6. 

When an interrupt is recognized by the Z8, 
all other interrupts are disabled, the program 
counter and program control flags are saved, and 
the program counter is loaded with the corres- 
ponding interrupt vector. Interrupts must be 
re -enabled by the user upon entering the service 
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Figure 5 Port Mode Registers 



R249 (F9„) Interrupt Priority Register (IPR; Write Only) 
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R249 INTERRUPT PRIORITY REGISTER (IPR) 
Figure 6 
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routine (for nested interrupts), or upon return- 
ing from the interrupt service routine using the 
IRET instruction. The interrupt cycle process 
is shown in Figure 7. 
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Figure 7 Interrupt Cycle Process 



INSTRUCTION SET 

The Z8 uses six address modes; Register, 
Indirect Register, Indexed, Direct, Relative, 
and Immediate. The Register mode refers to a 
register for operands. The Indirect Register 
mode refers indirectly through a register to an 
operand in a second register; indirectly through 
a register pair to an operand in program memory; 
or indirectly through a register pair to an 
operand in data memory. The Indexed mode is 
used only by the Load (LDJ instruction and pro- 
vides a method for generating an effective add- 
ress which is the sum of a register address 
(contained in the instruction) and the content 
of the index register. Tne Indexed mode employs 
Working Register area shortened notation for 
specifying the Index register. The Direct mode 
provides for a transfer of control to anywhere 
in program memory with a two byte address in the 
instruction. The Relative mode is used only 
with the Jump Relative, and Decrement And Jump 
instructions. The relative offset contained in 
the instruction allows a jump to an address 



which is "128 locations or +127 locations from 
the address of the instruction following the 
jump instruction. The Immediate mode provides 
the operand in the instruction. 

There are eight instruction functional 
groups; 



Load 

Arithmetic 
Logical 
Program Control 



Bit Manipulation 
Block Transfer 
Rotate and Shift 
CPU Control 



A summary of the Z8 instructions by function is 
given in Appendix A. 

The Z8 addressing modes are optimized for 
using the internal ROM and RAM memories . Two 
of the reasons why this was done were; to im- 
prove code density (fewer bytes per instruct- 
ion), and to reduce execution time. 

THE Z8 FAMILY 

The Z8 family emerged with three versions 
of the basic microcomputer; the 40 -pin RCM ver- 
sion, the 40 -pin EPROM version, and the 64 -pin 
version. The 40-pin EPROM version is offered 
in a Zilog proprietary package called a Proto- 
pak (see Figure 8j , that has a socket for an 
EPROM mounted permanently on top of a 40 -pin 
DIP. This device will plug directly into the 
socket of a product designed for the ROM ver- 
sion, or can be the initial production com- 
ponent for a product that may ultimately be 
converted to the RCM version of the Z8. The 64- 
pin version has no internal RCM and comes in a 
64 -pin leadless chip carrier (see figure 9) . 
The eleven ROM address lines and eight ROM data 
lines are brought to pins on this version of the 
Z8. A 4K ROM version of the Z8 is planned for 
release toward the end of 1980. 




Z8 Protopak 
Figure 8 





Z8/64 Package 
Figure 9 

ZS APPLICATION 

Typeset Innovations, Inc. is a company 
based in Austin, Texas, that has designed a 
graphics computing system based on the Z8 micro- 
computer. The ProGrafix is a specialized elec- 
tronic computational aid for use by graphics 
arts professionals in the sizing and pricing of 
graphic elements. Graphics arts professionals 
are exemplified by typesetting job estimators, 
typographers, graphic designers, printers, ad- 
vertising layout artists, and book and magazine 
designers. 

Graphic artists have in the past performed 
copyfitting through trial and error. With the 
increasing costs of graphics materials, the 
trial and error method has become a noticable 
expense that can be minimized with a more ac- 
curate copyfitting technique. 

The ProGrafix performs the following 
functions ; 

• Entry and display of values in the 
units of measurement which are 
commonly used in the typographical 
arts, including: 

picas 

points 

picas and points 

inches 



ciceros 

didots 

cieros and didots 

centimeters 

relative units 

• Instantaneous, one keystroke conversion 
of values between any of the above 
units of measurement. 

• Arithmetic operations using values 
which are expressed in any of the 
above units of measurement. 

• One keystroke execution of an extremely 
accurate copyfitting algorithm which 
finds any unknown copyfitting value 
after the five known ones have been 
entered, from among the following 

copy descriptors: 

width 

depth 

size 

leading 

type style density 

character count 

• Graphic proportional enlargement/ 
reduction computations by finding 
any one of the following values 
after the other two are entered: 

original size 
reproduction size 
enlargement/reduction ratio 

• Memory storage and recall of intermedi- 
ate results, pricing constants, and 
other user-created values. 

When final packaging is complete the Pro- 
Grafix will appear similar to the drawing 
shown in Figure 10. The computational aid will 
have an 8 digit display, 7 annunciator LED's to 
indicate measurement units, an on/off switch, 
and a 40 key keyboard matrix. The key funct- 
ions are defined in Table 1. 

When Typeset Innovations began the design 
of the ProGrafix early in 1980, they looked for 
a microcomputer that had the following charact- 
eristics; 

• A real (available) microcomputer 
powerful enough to do the job 

• Compact coding 

• Fast 

• Easy to program 

• External expansion of memory 
and I/O 
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ProGrafix Computational Aid 
Figure 10 



The Z8 offered all of these characteristics and 
more. By the second quarter of 1980, the Pro- 
Grafix prototypes were working. 

The prototype implementation is shown in 
Figure 11. External RCM and RAM were added 
using Port 1 and half of Port (A8-A11) . The 
ability to add more than 2K bytes of external 
memory with only 12 address lines _(A0-A11) is 
possible because the Data Strobe (DS) line is 
only active when locations above the first 2K 
bytes are accessed. Memory locations from to 
2K bytes are internal to the Z8; locations from 
2K bytes to 4K bytes (RCM) are external to the 
Z8 and selected by address line All=l and DS; 
and locations from 4K bytes to 6K bytes (RAM) 
are external to the Z8 and selected by address 
line All = and DS active. 

The remaining four bits of Port were 
used to drive the Unit of Measure LED's and the 
"sign" for the numeric display. 

Four of the I/O lines available from Port 3 
were used to select one of eight digits on the 
numeric display through a 4 to 16 decoder and to 
scan the rows of the keypad. The other four I/O 
lines were used to read back the columns from 
the keypad. 



One line from Port 2 was used for the fifth 
column input to the Z8 from the 40 key keypad. 
The remaining 7 I/O lines available from Port 2 
were used for segment select on the numeric dis- 
play. 

The numeric display is "scan refreshed" by 
the Z8 at a rate that is approximately 100 times 
per second. As the digits of the display are 
being refreshed the keypad is scanned as a mat- 
rix of 8 by 5 keys. The counter/ timers on the 
Z8 are both used; one to time the display re- 
fresh, and the other as a timer for keypad de- 
bounce. An external stack is used for temp- 
orary variable storage and during the servic- 
ing of interrupts. Only two Z8 interrupts are 
used by the ProGrafix, one for the display re- 
fresh counter and the other for the key de- 
bounce timer. 

The development of the software for the 
ProGrafix, which included a BCD Floating Point 
package, was done on a Zilog development system 
with the Z8 PLZ/ASM assembler. The object code 
was down loaded to a Z8 Development Module (DM) 
where the hardware was initially debugged. The 
external memory was added to the Z8EM in the 
space provided for wire wrap. When the system 
was 901 - 95% debugged, a prototype circuit 
board was built and the Z8 in a Protopak pack- 
age with an EPR0M was used for final system de- 
bug. 

The production version of the ProGrafix 
will use an LCD numeric display instead of the 
LED display. This will make additional address 
lines available for expanding off chip memory. 
In addition, a printer option is planned that 
will connect to the serial port of the Z8. 

The ProGrafix is expected to sell for under 
$500 without a printer and under $750 with a 
printer. The availability of the ProGrafix has 
been targeted for May of 1981. 

The configuration of the ProGrafix com- 
putational aid around the Z8 provided a very 
flexible and powerful microcomputer system that 
can be expanded to accomodate a wide variety of 
applications by simply changing the software. 
Typeset Innovations is currently looking for 
other products that can be implemented with the 
hardware that was developed for the ProGrafix. 

CONCLUSION 

The Z8 represents the coming of age of the 
more powerful microcomputers. While the Z8 can 
be a cost effective design solution for low end 
applications, it can also be expanded to attack 
much more sophisticated design problems. The 
architecture of the Z8 was designed in a forward 
looking manner, and the integration of more cap- 
ability onto the same chip is now limited only 
by the constraints of the integrated circuit 
technology. 
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TABLE 1 



ProGrafix Key Functions 



Key 10 designated as C clears display register 
X and the operand register Y. 

Key 11 designated as CE, the clear-entry func- 
tion, clears only the last value entered into 
display register X. 

Key 12 designated as RECALL enters the contents 
of a designated memory register through 9 in- 
to register X and into the display. 

Key 13 designated STORE stores display register 
X into memory registers through 9, and into 
the parameter registers. 

Key 14 designated as ORIG which is used to store 
or recall the value of the original size para- 
meter in the proportional sizing algorithm. 

Key 15 designated as WIDTH which is used to 
store or recall the value of the width (line 
length) parameter of the copy fitting algorithm. 

Key 16 designated as PICA which provides for the 
function of entering information in picas and 
points and for converting information on the 
display into either picas and points or decimal 
picas. 

Key 17 designated as CICERO which provides for 
the function of entering information in ciceros 
and for converting information on the display 
into either ciceros and didots or decimal 
ciceros . 

Key 18 designated as REL-UN which provides for 
the function of entering information in relative 
units and for converting information on the dis- 
play into relative units. 

Key 19 designated as REPRO which is used to 
store or recall the value of the reproduction 
size parameter in the proportional sizing al- 
gorithm. 

Key 20 designated as DEPTH which is used to 
store or recall the value of the depth (vertical 
measure) parameter of the copyfitting algorithm. 

Key 21 designated as POINT which provides for 
the function of entering information in points 
and for converting the information on the dis- 
play into points. 

Key 22 designated as DIDOT which provides for 
the function of entering information in didot 
points and for converting the information on 
the display into didot points. 

Key 23 designated as RU/EM which is used to 
store or recall of the relative units per em 
space parameter. 

Key 24 designated as RATIO which is used to 
store or recall the value of the ratio para- 
meter in the proportional sizing algorithm. 



Key 25 designated as SIZE which is used to store 
or recall the value of the type size parameter 
for the copyfitting algorithm and for the re- 
lative units conversion algorithm. 

Key 26 designated as INCH which provides for the 
function of entering information in inches and 
for converting the information on the display 
into inches. 

Key 27 designated as CM which provides for the 
dual function of entering information in centi- 
meters, and for converting the information on 
the display into centimeters. 

Key 28 designated as "double arrow" interchanges 
the contents of display register X and operand 
register Y. 

Key 29 designated as '/• (the divide sign) 
divides operand register Y by display register 
X. 

Key 30 designated as LEAD which is used to store 
or recall the value of the leading (line spac- 
ing) parameter of the copyfitting algorithm. 

Key 31 designated as x multiples display regist- 
er X by operand register Y. 

Key 32 designated as DENSITY which is used to 
store or recall the value of the type style 
density parameter of the copyfitting algorithm. 

Key 33 designated as + adds display register X 
to operand register Y. 

Key 34 designated as CHAR which is used to store 
or recall the value of the character count para- 
meter of the copyfitting algorithm. 

Key 35 designated as - subtracts display reg- 
ister X from operand register Y. 

Key 36 designated as FIND invokes the calcula- 
tion of an unknown copyfitting parameter given 
five known copyfitting parameters. This key 
is also used to solve for an unknown proport- 
ional sizing parameter given two known proport- 
ional sizing parameters. 

Key 37 designated . is used to enter the decimal 
point of a floating-point number. 

Key 38 designated as +/- reverses the sign of 
the value in display register X. 

Key 39 designated as = invokes the last entered 
arithmetic operation using the X and Y registers 
as operands and places the result in display 
register X. 

Key 40 designated as ON/OFF powers the micro- 
computer system on and off. 
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APPENDIX A 



Z8 Instruction Set: Functional Groups 



Load Instructions 



Instruction Operand (s) Name of 

Instruction 



CLR 
LD 
LDC 
LDE 

POP 
PUSH 



dst 




dst , 


src 


dst , 


src 


dst , 


src 


dst 




src 





Clear 

Load 

Load Constant 

Load External 

Data 
Pop 
Push 



Arithmetic Instructions 



Instruction Operand (s) Name of 

Instruction 

ADC dst, src Add With Carry 

ADD dst, src Add 

CP dst, src Compare 

DA dst Decimal Adjust 

DEC dst Decrement 

DECW dst Decrement Word 

INC dst Increment 

INCW dst Increment Word 

SBC dst, src Subtract With 

Carry 

SUB dst, src Subtract 



Logical Instructions 



Instruction Operand (s) Name of 

Instruction 

AND dst, src Logical And 

COM dst Complement 

OR dst, src Logical Or 

XOR dst, src Logical 

Exclusive 
Or 



Program-Control Instructions 

Instruction Operand (s) Name of 

Instruction 

CALL dst Call 

DJNZ r, dst Decrement and 

Jump If Nonzero 

IRET Interrupt Return 

JP cc, dst Jump 

JR cc, dst Jump Relative 

RET Return 



1-13 



APPENDIX A (cont.) 



Bit-Manipulation Instructions 

Instruction Operands Name of 

Instruction 

TCM dst, src Test Complement 

Under Mask 
TM dst, src Test Under Mask 

AND dst, src Logical And 

OR dst, src Logical Or 

XOR dst, src Logical 

Exclus lve 
Or 



Block-Transfer Instructions 



Instruction Operands Name of 

Instruction 

LDCI dst, src Load Constant 

Aut ©increment 

LDEI dst, src Load External 

Data Auto- 
increment 



Rotate and Shift Instructions 



Instruction Operand Name of 

Instruction 

RL dst Rotate Left 

RLC dst Rotate Left 

Through Carry 
RR dst Rotate Right 

RRC dst Rotate Right 

Through Carry 
SRA dst Shift Right 

Arithmetic 
SWAP dst Swap Nibbles 

CPU Control Instructions 



Instruction Operand Name of 

Instruction 

CCF Complement Xarry 

Flag 

DI Disable 

Interrupts 

EI Enable 

Interrupts 

NOP No Operation 

RCF Reset Carry Flag 

SCF Set Carry Flag 

SRP sre Set Register 

_______^_ P oin ter 
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INTRODUCTION 

The microcomputer industry has recently developed 
single-chip microcomputers that incorporate on one 
chip functions previously performed by periph- 
erals. These microcomputer units (MCUs) are aimed 



at markets requiring a dedicated computer. This 
report describes and compares the most powerful 
MCUs in today's market: the Zilog Z8611, the 
Intel 8051, and the Motorola MC6801 . Table 1 
lists facts that should be considered when com- 
paring these MCUs. 



Table 1. MCU Comparison 



FEATURES 


Zilog 
Z8611 


Intel 
8051 


Motorola 
MC6801 


On-Chip ROM 


4Kx8 


4Kx8 


2Kx8 


General-Purpose 
Registers 


124 


128 


128 


Speci al-Funct ion 
Registers 

Status/Control 
I/O ports 


16 
4 


16 
4 


17 
4 


I/O 

Parallel lines 

Ports 

Handshake 


32 

Four 8-bit 
Hardware on 
three ports 


32 

Four 8-bit 

None 


29 

Three 8-bit, one 5-bit 
Hardware on 
one port 


Interrupts 

Source 

External source 
Vector 
Priority 

Maskable 


8 
4 
6 
48 Programmable 

orders 
6 


5 
2 
5 
2 Programmable 

orders 
5 


7 
2 
7 
Nonprogrammable 

6 


External 
Memory 


120K bytes 


124K bytes 


64K bytes 


Stack 

Stack pointer 
Internal stack 

External stack 


16-Bit 
Yes, uses 
8-bits 
Yes 


8-Bit 
Yes 

No 


16-Bit 
Yes 

Yes 



IK" 
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Table 1. MCU Comparison 
(Continued) 





Zilog 
Z8611 


Intel 


Motorola 


FEATURES 


8051 


MC6801 


Counter/ 








Timers 








Counters 


Two 8-bit 


Two 16-bat 
or two 8-bit 


One 16-bit 


Prescalers 


Two 6-bit 


No prescale 

with 16-bits; 
5-bit prescale 

with 8-bits 


None 


Addressing 








Modes 








Register 


Yes 


Yes 


No 


Indirect Register 


Yes 


Yes 


No 


Indexed 


Yes 


Yes 


Yes 


Direct 


Yes 


Yes 


Yes 


Relative 


Yes 


Yes 


Yes 


Immediate 


Yes 


Yes 


Yes 


Implied 


Yes 


Yes 


Yes 


Index 








Registers 


124, Any 


1, Uses the 


1, Uses 




general- 


accumulator 


16-bit index 




purpose 


for 8-bit 


register 




register 


offset 




Serial 








Communication 








Interface 








Full duplex 








UART 


Yes 


Yes 


Yes 


Interrupts 








for transmit 








and receive 


One for each 


One for both 


One for both 


Registers 








Double buffer 


Receiver 


Receiver 


Transmitter/Receiver 


Serial Data Rate 


62. 5K b/s 


187. 5K b/s 


62. 5K b/s 




@8 MHz 


@12 MHz 


@4 MHz 




93. 5K b/s 








@12 MHz 






Speed 








Instruction 








execution average 


2.2 Usee 

1.5 Usee ®12 MHz 


1.5 Usee 


3.9 Usee 


Longest 








instruction 


4.25 Usee 

2.8 Usee ©12 MHz 


4 Usee 


10 Usee 


Clock Frequency 


8 and 12 MHz 


12 MHz 


4 MHz 


Power Down 


Saves first 


Saves first 


Saves first 


Mode 


124 registers 


128 registers 


64 registers 


Context 


Saves PC 


Saves PC; 


Saves PC, PSW, 


Switching 


and flags 


programmer 


accumulators, 






must save all 


and Index 






registers 


register 
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Table 1. MCU Comparison 
(Continued) 



FEATURES 


Zilog 
Z8611 


Intel 
8051 


Motorola 
MC6801 


Development 


40- Pin 

Protopack (8613) 
64- Pin (8612) 
40-Pin ROMless 

(Z8681 ) 


40-Pm (8751) 


40- Pin (68701) 


Eprom 
Availability 


4K bytes (2732) 
2K bytes (2716) 

Now 


4K bytes 
TBA 


2K bytes 
Now 



ARCHITECTURAL OVERVIEW 

This section examines three chips: the on-chip 
functions and data areas manipulated by the Zilog, 
Intel and Motorola MCUs. The three chips have 
somewhat similar architectures. There are, how- 
ever, fundamental differences in design criteria. 
The 8051 and the MC6801 were designed to maintain 
compatability with older products, whereas the 
Z8611 design was free from such restrictions and 
could experiment with new ideas. Because of this, 
the accumulator architectures of the MC6801 and 
the 8051 are not as flexible as that of the Z8611, 
which allows any register to be used as an accumu- 
lator. 



Memory Spaces 

The Z8611 CPU manipulates data in four memory 
spaces: 

• 60K bytes of external data memory 

e 60K bytes of external program memory 

• 4K bytes of internal program memory (ROM) 
e 144-byte register file 

The 8051 CPU manipulates data in four memory 
spaces: 

• 64K bytes of external data memory 

• 60K bytes of external program memory 

• 4K bytes of internal program memory 

• 148-byte register file 

The MC6801 manipulates data in three memory 
spaces: 



• 62K bytes of external memory 

e 2K bytes of internal program memory 

• 149-byte register file 



required with the MC6801 that is not necessary 
with the Z8611 or the 8051. 



On Chip RAM. All three chips use internal RAM as 
registers. These registers are divided into two 
catagories: general-purpose registers and special 
function registers (SFRs). 

The 124 general-purpose registers in the Z8611 are 
divided into eight groups of 16 registers each. 
In the first group, the lowest four registers are 
the 1/0 port registers. The other registers are 
general purpose and can be accessed with an 8-bit 
address or a short 4-bit address. Using the 4-bit 
address saves bytes and execution time. Four-bit 
short addresses are discussed later. The general- 
purpose registers can be used as accumulators, ad- 
dress pointers, or Index registers. 



The 128 general-purpose registers in the 8051 are 
grouped into two sets. The lower 32 bytes are 
allocated as four 8-register banks, and the upper 
registers are used for the stack or for general 
purpose. The registers cannot be used for index- 
ing or as address pointers. 

The MC6801 also has a 128-byte, general-purpose 
register bank, which can be used as a stack or as 
address pointers, but not as Index registers. 

As pointed out in Table 1, any of the Z8611 
general-purpose registers can be used for index- 
ing; the MC6801 and the 8051 cannot use registers 
this way. The Z8611 can use any register as an 
accumulator; the MC6801 and the 8051 have fixed 
accumulators. The use of registers as memory 
pointers is very valuable, and only the Z8611 can 
use its registers in this way. 



On-Chip ROM. All three chips have internal ROM 
for program memory. The Z8611 and the 8051 have 
4K bytes of internal ROM, and the MC6801 has 2K 
bytes. In some cases, external memory may be 



The number of general-purpose registers on each 
chip is comparable. However, because of its 
flexible design, the Z8611 clearly has a more 
powerful register architecture. 
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The Z8611 has 20 special function registers used 
for status, control, and I/O. These registers 
include: 

• Two registers for a 16-bit Stack Pointer (SPH, 
SPL) 

• One register used as Register Pointer for 
working registers (RP) 

• One register for the status flags (FLAGS) 

• One register for interrupt priority (IPR) 

• One register for interrupt mask (IMR) 

• One register for interrupt request (IRQ) 

e Three mode registers for the four ports (P01M, 

P2M, P3M) 
9 Serial communications port used like a 

register (SIO) 

• Two counter/timer registers (TO, T1) 

• One Timer Mode Register (TMR) 

• Two prescaler registers (PREO, PRE1) 

• Four I/O ports accessed as registers (PORTO, 
P0RT1, P0RT2, P0RT3) 

The 8051 also has 20 special function registers 
used for status, control, and I/O. They include: 

• One register for the Stack Pointer (SP) 

• Two accumulators (A,B) 

• One register for the Program Status Word 
(PSW) 

• Two registers for pointing to data memory 
(DPH, DPL) 

• Four registers that serve as two 16-bit 
counter/timers (THO, TH1 , TLO, TL1 ) 

• One mode register for the counter/timers 
(TMOD) 

• One control register for the counter/timers 
(TCON) 

• One register for interrupt enable (IEC) 

• One register for interrupt priority (IPC) 

• One register for serial communications buffer 
(SBUF) 

• One register for serial communications control 
(SCON) 

• Four registers used as the four I/O ports (P0, 
P1, P2, P3) 

The MC6801 has 21 special function registers used 
for status, control, and I/O. These include: 

• One register for RAM/EROM control 

• One serial receive register 

• One serial transmit register 

• One register for serial control and status 

• One serial rate and mode register 

• One register for status and control of port 3 

• One register for status and control of the 
timer 

• Two registers for the 16-bit timer 

• Two registers for 16-bit input capture used 
with timer 

• Two registers for 16-bit output compare used 
with timer 

• Four data direction registers associated with 
the four I/O ports 

• Four I/O ports 



The special function registers in the three chips 
seem comparable in number and function. However, 
upon closer examination, the SFRs of the MC6801 
prove less efficient than those of the Z8611. The 
MC6801 has five registers associated with the I/O 
ports, whereas the Z8611 uses only three registers 
for the same functions. The MC6801 uses four 
registers to perform the serial communication 
function, whereas the Z861 1 uses only one register 
and part of another. 

The 8051 uses two registers for the accumulators; 
the Z8611 is not limited by this restriction. The 
8051 also uses two registers for the serial com- 
munication interface, whereas the Z8611 accom- 
plishes the same job with one register. Another 
two registers in the 8051 are used for data 
pointers; these are not necessary in the Z8611 
since any register can be used as an address 
pointer. 

The Z8611 uses registers more efficiently than 
either the MC6801 or the 8051 . The registers saved 
by this optimal design are used to perform the 
functions needed for enhanced interrupt handling 
and for register pointing with short addresses. 
The Z8611 also supplies the extra register re- 
quired for the external stack. These features are 
not available on the 8051 or the MC6801 . 

External Memory. All three chips can access 
external memory. The Z8611 and the 8051 can gen- 
erate signals used for selecting either program or 
data memory. The Data Memory strobe (the signal 
used for selecting data or program memory) gives 
the Z8611 access to 120K bytes of external memory 
(60K bytes in both program and data memory). The 
8051 can use 124K bytes of external memory (64K 
bytes of external data memory and 60K bytes of 
external program memory). The MC6801 can access 
only 62K bytes of external memory and does not 
distinguish between program and data memory. Thus, 
the Z8611 and the 8051 are clearly able to access 
more external memory than the MC6801. 



On-Oiip Peripheral Functions 

In addition to the CPU and memory spaces, all 
chips provide an interrupt system and extensive 
1/0 facilities including 1/0 pins, parallel 1/0 
ports, a bidirectional address/ data bus, and a 
serial port for 1/0 expansion. 



Interrupts. The Z.8611 acknowledges interrupts 
from eight sources, four are external from pins 
IRQ0-IRQ3, and four are internal from serial-in, 
serial-out, and the two counter/timers. All 
interrupts are maskable, and a wide variety of 
priorities are realized with the Interrupt Mask 
Register and the Interrupt Priority Registers (see 
Table 1). All Z8611 interrupts are vectored, with 
six vectors located in the on-chip ROM. The 
vectors are fixed locations, two bytes long, that 
contain the memory address of the service routine. 
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The 8051 acknowledges interrupts from five 
sources: two external sources (from INTO and 
INT1 ) and three internal sources (one from each of 
the internal counters and one from the serial I/O 
port). All interrupts can be disabled individual- 
ly or globally. Each of the five sources can be 
assigned one of two priorities: high or low. All 
8051 interrupts are vectored. There are five 
fixed locations in memory, each eight bytes long, 
allocated to servicing the interrupt. 

The MC6801 has one external interrupt, one non- 
maskable interrupt, an internal interrupt request, 
and a software interrupt. The internal interrupts 
are caused by the serial I/O port, timer overflow, 
timer output compare, and timer input capture. 
The priority of each interrupt is preset and can- 
not be changed. The external interrupt can be 
masked in the Condition Code register. The MC6801 
vectors the interrupts to seven fixed addresses in 
ROM where the 16-bit address of the service 
routine is located. 

When an interrupt occurs in the 8051, only the 
Program Counter is saved; the user must save the 
flags, accumulator, and any registers that the 
interrupt service routine might affect. The 
MC6801 saves the Program Counter, acumulators, 
Index register, and the PSW; the user must save 
all registers that the interrupt service routine 
might affect. The Z8611 saves the Program Counter 
and the Flags register. To save the 16 working 
registers, only the Register Pointer register need 
be pushed onto the stack and another set of work- 
ing registers is used for the service routine. 
For more detail on working registers and interrupt 
context switching, see the Z8 Technical Manual 
(03-3047-02). 

With regard to interrupts, the Z8611 is clearly 
superior. The Z8611 requires only one command to 
save all the working registers, which greatly 
increases the efficiency of context switching. 



1/0 Facilities. The Z8611 has 32 lines dedicated 
to 1/0 functions. These lines are grouped into 
four ports with eight lines per port. The ports 
can be configured individually under software 
control to provide input, output, multiplexed 
address/data lines, timing, and status. Input and 
output can be serial or parallel, with or without 
handshake. One port can be configured for serial 
transmission and four ports can be configured for 
parallel transmission. With parallel transmis- 
sion, ports 0, 1, and 2 can transmit data with the 
handshake provided by port 3. 

The 8051 also has 32 1/0 lines grouped together 
into four ports of eight lines each. The ports can 
be configured under program control for parallel 
or serial 1/0. The ports can also be configured 
for multiplexed address/data lines, timing, and 
status. Handshake is provided by user software. 

The MC6801 has 29 lines for 1/0 (three 8-bit ports 
and one 5-bit port). One port has two lines for 



handshake. The ports provide all the signals 
needed to control input and output either serially 
or in parallel, with or without multiplexed 
address/data lines. They can be used to interface 
with external memory. 

The main differences in 1/0 facilities are the 
number of 8-bit ports and the hardware handshake. 
The Z8611 and the 8051 have four 8-bit ports, 
whereas the MC6801 has three 8-bit ports and an 
additional 5-bit port. The Z8611 has hardware 
handshake on three ports, the MC6801 has hardware 
handshake on only one port, and the 8051 has no 
hardware handshake. 



Counter/timers. The Z8611 has two 8-bit counters 
and two 6-bit programmable prescalers. One pre- 
scaler can be driven internally or externally; the 
other prescaler is driven internally only. Both 
timers can interrupt the CPU when counting is 
completed. The counters can operate in one of two 
modes: they can count down until interrupted, or 
they can count down, reload the initial value, and 
start counting down again (continuously). The 
counters for the Z8611 can be used for measuring 
time intervals and pulse widths, generating vari- 
able pulse widths, counting events, or generating 
periodic interrupts. 

The 8051 has two 16-bit counter/timers for measur- 
ing time intervals and pulse widths, generating 
pulse widths, counting events, and generating 
periodic interrupts. The counter/timers have 
several modes of operation. They can be used as 
8-bit counters or timers with two 5-bit program- 
mable prescalers. They can also be used as 16-bit 
counter/timers. Finally, they can be set as 8-bit 
modulo-n counters with the reload value held in 
the high byte of the 16-bit register. An interrupt 
is generated when the counter/timer has completed 
counting. 

The MC6801 has one 16-bit counter which can be 
used for pulse-width measurement and generation. 
The counter/timer actually consists of three 
16-bit registers and an 8-bit control/status reg- 
ister. The timer has an input capture register, 
an output compare register, and a free-running 
counter. All three 16-bit registers can generate 
interrupts. 



Serial Communications Interface. The Z8611 has a 
programmable serial communication interface. The 
chip contains a UART for full-duplex, asynchron- 
ous, serial receiver/ transmitter operation. The 
bit rate is controlled by counter/timer and has 
a maximum bit rate of 93.500 b/s. An interrupt is 
generated when an assembled character is transfer- 
red to the receive buffer. The transmitted 
character generates a separate interrupt. The 
receive register is double-buffered. A hardware 
parity generator and detector are optional. 

The 8051 handles serial 1/0 using one of its 
parallel ports. The 8051 bit rate is controlled 
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by counter/timer 1 and has a maximum bit rate of 
187,500 b/s. The 8051 generates one interrupt for 
both transmission and receipt. The receive reg- 
ister is double-buffered. 

The MC6801 contains a full-duplex, asynchronous, 
serial communication interface. The bit rate is 
controlled by a rate register and by the MCU's 
clock or an external clock. The maximum bit rate 
is 62,500 b/s. Both the transmit and the receive 
registers are double-buffered. The MC6801 gener- 
ates only one interrupt for both transmit and 
receive operations. No hardware parity generation 
or detection is available, although it does have 
automatic detection of framing errors and overrun 
conditions. 

The 8051 and the MC6801 generate only one inter- 
rupt for both transmit and receive, whereas the 
Z8611 has a separate interrupt for each. The 
ability to generate separate interrupts greatly 
enhances the use of serial communications, since 
separate service routines are often required for 
transmitting and receiving. 

Other differences between the Z8611, MC6801 , and 
the 8051 occur in the hardware parity detector, 
the double-buffering of registers, framing error 
detectors and overrun conditions. The 8051 has a 
faster data rate than either the Z8611 or the 
MC6801 . The MC6801 has the advantage of a hard- 
ware framing error detector and automatic detec- 
tion of overrun conditions. The MC6801 also has 
both its transmit and receive registers 
double-buffered. The Z8611 has a hardware parity 
detector. For detection of framing errors and 
overrun conditions, a simple, low-overhead soft- 
ware check is available that uses only two 
instructions. See Z8600 Software Framing Error 
Detection Application Brief (document #617-1881- 
0004). 



INSTRUCTION ARCHITECTURE 

The architecture of the Z8611 is designed specif- 
ically for microcomputer applications. This fact 
is manifest in the instruction composition. The 
arduous task of programming the MC6801 and the 
8051 starkly contrasts that of programming the 
Z8611. 



Addressing Modes 

The Z8611 and the 8051 both have six addressing 
modes; Register, Indirect Register, Indexed, 
Direct, Relative, and Immediate. The MC6801 has 
five addressing modes: Accumulator, Indexed, 
Direct, Relative, and Immediate. A quick compar- 
ison of these addressing modes reveals the versa- 
tility of the Z8611 and the 8051. The addressing 
modes of the MC6801 have several restrictions, as 
shown in Table 1. While the 8051 has all the 
addressing modes of the Z8611, its use of them is 
restricted. The Z8611 allows many more combina- 



tions of addressing modes per instruction, because 
any of its registers can be used as an accumula- 
tor. For example, the instructions to clear, 
complement, rotate, and swap nibbles are all 
accumulator oriented in the 8051 and operate on 
the accumulator only. These same commands in the 
Z8611 can use any register and access it either 
directly, with register addressing, or with in- 
direct register addressing. 



Indexed Addressing. All three chips differ in 
their handling of indexing. The Z8611 can use any 
register for indexing. The 8051 can use only the 
accumulator as an Index register in conjunction 
with the data pointer or the Program Counter. The 
MC6801 has one 16-bit Index register. The address 
located in the second byte of an instruction is 
added to the lower byte of the Index register. 
The carry is added to the upper byte for the com- 
plete address. The MC6801 requires the index 
value to be an immediate value. 

The MC6801 has only one 16-bit Index register and 
an immediate 8-bit value from the second byte of 
the instruction. Hence, the Indexed mode of the 
MC6801 is much more restrictive than that of the 
Z8611. The 8051 must use the accumulator as its 
only Index register, loading the accumulator with 
the register address each time a reference is 
made. Then, using indexing, the data is moved 
into the accumulator, eradicating the previous 
index. This forces a stream of data through the 
accumulator and requires a reload of the index 
before access can be made again. The Z8611 is 
clearly superior to both the MC6801 and the 8051 
in the flexibility of its indexed addressing mode. 



Short and Long Addressing* Short addressing helps 
to optimize memory space and execution speed. In 
sample applications of short register addressing, 
an eight percent decrease in the number of bytes 
used was recorded. 

All three chips have short addressing modes, but 
the Z8611 has short addressing for both external 
memory and register memory. The 8051 has short 
addressing for the lowest 32 registers only. 

The Z8611 has two different modes for register 
addressing. The full-byte address can be used to 
provide the address, or a 4-bit address can be 
used with the Register Pointer. To use the work- 
ing registers, the Register Pointer is set for a 
particular bank of 16 registers, and then one of 
the 16 registers is addressed with four bits. 
Another feature for addressing external memory is 
the use of a 12-bit address in place of a full 
16-bit address. To use the 12-bit address, one 
port supplies the eight multiplexed address/data 
lines and another port supplies four bits for the 
address. The remaining four bits of the second 
port can be used for 1/0. This feature allows 
access to a maximum of 10K bytes of memory. 
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The 8051 uses short addresses by organizing its 
lowest 32 registers into four banks. The bank 
select is located in a 2-bit field in the PSW, 
with three bits addressing the register in the 
bank. 

The MC6801 uses extended addressing for addressing 
external memory. With a special, nonmultiplexed 
expansion mode, 256 bytes of external memory can 
be accessed without the need for an external 
address latch. The MC6801 uses one 8-bit port for 
the address and another port for the data. 
Stacks 



with its 8051 family. The 8031 has no internal 
ROM and the 8751 has 4K of internal EPROM. 

Motorola offers the MC6801 , MC6803, MC6803NR, and 
MC68701. These are all similar except the MC68701 
has 2K bytes of EPROM and the MC6801 has 2K bytes 
of ROM. The MC6803 has no internal ROM and the 
MC6803NR has neither ROM nor RAM on board. 

The Z8613 and the MC68701 are both available now, 
but the 8751 is still unavailable (as of April 
1981). 



The Z8611 and the MC6801 provide for external 
stacks, which require a 16-bit Stack Pointer. 
Internal stacks use only an 8-bit Stack Pointer. 
The 8051 uses only a limited internal stack re- 
quiring an 8-bit Stack Pointer. Using an external 
stack saves the internal RAM registers for 
general-purpose use. 



Summary 

The stack structure of the Z8611 and the MC6801 is 
better than that of the 8051. In most applica- 
tions, the 8051 is more flexible and easier to 
program than the MC6801 . The Z8611 is easier to 
use than either the 8051 or the MC6801 because of 
its register flexibility and its numerous combina- 
tions of addressing modes. The 8051 features a 
unique 4><6n multiply and divide command. The 
MC6801 has a multiply, but it takes 10/^-s to per- 
form it. 

In summary, the Z8611 has the most flexible 
addressing modes, the most advanced indexing capa- 
bilities, and superior space- and time-saving 
abilities with respect to short addressing. 



DEVELOPMENT SUPPORT 

All three vendors provide development support for 
their products. This section discusses the dif- 
ferent support features, including development 
chips, software, and modules. 



Software 

Development software includes assemblers, and 
conversion programs. All manufacturers offer some 
or all of these features. 

Since the MC6801 is compatible with the 6800, 
there is no need for a new assembler. The Z8611 
and the 8051 both offer assemblers for their 
products. The Zilog PLZ/ASM assembler generates 
relocatable and absolute object code. PLZ/ASM 
also supports high-level control and data state- 
ments, such as IF... THEN... ELSE. Intel offers an 
absolute macroassembler, ASM51, with their 
product. They also offer a program for converting 
8048 code to 8051 code. 



Modules 

The Z8611 development module has two 64-pin 
development versions of the 40-pin, ROM-masked 
Z8611. Intel offers the EM-51 emulation board, 
which contains a modified 8051 and PROM or EPROM 
in place of memory. Motorola has the MEX6801EVM 
evaluation board for program development. All 
three development boards are available now. 



ADDITIONAL FEATUfKS 

Additional features include Power Down mode, self- 
testing, and family-compatibility. 



Chips 

Zilog offers an entire family of microcomputer 
chips for product development and final product. 
The Z8611 is a single-chip microcomputer with 4K 
bytes of mask-programmed ROM. For development, two 
other chips are offered. The Z8612 is a 64-pin, 
development version with full interface to ex- 
ternal memory. The Z8613 is a prototype version 
that uses a functional, piggy-back, EPROM proto- 
pak. The Z8613 can use either a 4K EPROM (2732) 
or a 2K EPROM (2716). Zilog also offers a ROMless 
version in a 40-pin package that has all the fea- 
tures of the Z8611 except on-board ROM (Z8681). 



Intel offers a similar line of development chips the V pc j pin. 



Power Down Mode 

All three microcomputers offer a Power Down mode. 
The Z8611 and the 8051 save all of their regis- 
ters with an auxilary power supply. The MC6801 
uses an auxiliary power supply to save only the 
first 64 bytes of its register file. 

The Z8611 uses one of the crystal input pins for 
the external power supply to power the registers 
in Power Down mode. Since the XTAL2 input must be 
used, an external clock generator is necessary and 
is input via XTAL1. The 8051 and the MC6801 both 
have an input reserved for this function. The 
MC6801 uses the V cc standby pin, and the 8051 uses 



751-1534-0002 



1-21 



4-23-81 



Family Compatibility 



Program Listings 



Another strength of the Z8611 is its expansion 
bus, which is completely compatible with the Zilog 
Z-BUS™. This means that all Z-BUS peripherals 
can be used directly with the Z861 1 . 

The MC6801 is fully compatible with all MC6800 
family products. The 8051 is software compatible 
with the older 8048 series and all others in that 
family. 



BENCHMARKS 

The following benchmark tests were used in this 
report to compare the Z8611, 8051, and MC6801 : 

• Generate CRC check for 16-bit word. 

• Search for a character in a block of memory. 

• Execute a computed GOTO - jump to one of eight 
locations depending on which of the eight bits 
is set. 

• Shift a 16-word five places to the right. 

• Move a 64-byte block of data from external 
memory to the register file. 

• Toggle a single bit on a port. 

• Measure the subroutine overhead time. 

These programs were selected because of their 
importance in microcomputer applications. Algo- 
rithms that reflect a unique function or feature 
were excluded for the sake of comparison. Al- 
though programs can be optimized for a particular 
chip and for a particular attribute (code density 
or speed) these programs were not. 

The figures cited in this text are taken directly 
from the vendor's documentation. Therefore, the 
cycles given below for the MC6801 and the 8051 are 
in machine cycles and the Z861 1 figures are given 
in clock cycles. The Z8611 clock cycles should be 
divided by six to give the instruction time in 
microseconds. The 8051 and MC6801 machine cycle 
is 1As, and the Z8611 clock cycle is i166/cs at 
12 MHz. 

Because of the lack of availability of the MC6801 
and the 8051, the benchmark programs listed here 
have not yet been run. When these products are 
readily available, the programs will be run and 
later editions of this document will reflect any 
changes in the findings. 
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N = 20+66X7+64 = 546 cycles 
812 MHz = 91 M-s 
Instructions = 12 
Bytes = 22 
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Character Search Through Block of 40 Bytes 



Shift 16-Bit Word to Right 5-Bits 



8051 




Machine 




8051 






Machine 








Cycles 


Bytes 








Cycles 


Bytei 


MOV 


INDEX, #41 


1 


2 




MOV 


INDEX #5 




2 


MOV 


DPTR, #TABLE 


2 


3 


LOOP: 


CLR 


C 




1 


L00P1: DJNZ 


INDEX, LOOP 2 


2 


2 




MOV 


A, WORD + 1 




2 


SJMP 


OUT 


2 


2 




RRC 


A 




1 


L00P2: MOV 


A, INDEX 


1 


2 




MOV 


WORD + 1 , A 




2 


MOVC 


A, (1A+DPTR 


2 


1 




MOV 


A, WORK 




2 


CJNE 


A, CHARAC, L00P1 2 


3 




RRC 


A 




1 


OUT: 










MOV 


WORD, A 




2 


N = 


3+39X7+4 = 280 


cycles 






DJNZ 


INDEX, LOOP 


2 


2 


@12 MHz = ZQOals 








N = 1+9X5 = 46 Cycles 






Instructions = 7 








@12 


MHz = 46*ts 






Bytes = 15 








Instructions = 9 
















Byt 


es = 15 






MC6801 




Machine 


















Cycles 


Bytes 


MC6801 




Machine 




LDAB 


#$40 


2 


2 








Cycles 


Bytes 


LDAA 


#CHARAC 


2 


2 




LDX 


#5 


6 


3 


LDX 


#TABLE 


3 


3 




LDAD 


WORK 


4 


2 


LOOP: CMPA 


$0, X 


4 


2 


LOOP: 


LSRD 




3 


1 


BEQ 


OUT 


4 


2 




DEX 




3 


1 


I NX 




3 


1 




BNE 


LOOP 


4 


2 


DECB 




2 


1 




STAD 


WORD 


4 


2 


BNE 


LOOP 


4 


2 




N = 10X5+11 = 61 Cycles 






OUT: - 










m 


MHz r 61 #JG 






- 










Instructions = 6 






- 










Byt 


es = 11 






N = 7+40X17 = 687 cycles 














@4 


MHz = 6874cs 
















Instructions = 8 






Z8611 






Clock 




Byt 


es = 15 








LD 


INDEX, #5 


Cycles 

6 


Bytes 

2 


Z8611 




Clock 




LOOP: 


CCF 




6 


1 






Cycles 


Bytes 




RRC 


WORD + 1 


6 


2 


LD 


INDEX, #40 


6 


2 




RRC 


WORD 


6 


2 


LOOP: LD 


DATA, TABLE (INDEX) 10 


3 




DJNZ 


INDEX, LOOP 


12 or 10 


2 


CP 


DATA, CHARAC 


6 


2 




N = 6+4X30+28 = 154 Cycles 




JR 


Z, OUT 


12 or 10 


2 




@12 


MHz = 26 *s 






DJNZ 


INDEX, LOOP 


12 or 30 


2 




Instructions = 5 






OUT: - 










Byt 


es = 9 







N = 6+38X40 = 1524 cycles 
®12 MHz = 254*.s 
Instructions = 5 
Bytes = 11 



751-1534-0002 



1-23 



4-23-81 





Computed GOTO 
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Results 

Table 2 summarizes the results of this comparison. 
The relative performance column lists the speeds 
of the MC6801 and 8051 divided by the Z8611 speeds 
(12 MHz). The overall performance averages the 
separate relative performances. The higher the 
number, the faster the Z8611 as compared to the 
MC6801 and the 8051. 

The relative performance figures show that the 
Z8611 runs 50 percent faster than the 8051 and 250 
percent faster than the MC6801 . Although speed is 
not necessarily the most important criterion for 
selecting a particular product, the Z861 1 proves 
to be an undeniably superior product when speed is 
added to the advantages of programming ease, code 
density, and flexibility. 
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Table 2. Benchmark Program Results 



Benchmark 
Test 


MC6801 

(4 MHz) 

cycles time 


8051 

(12 MHz) 

cycles time 


Z8 

(8 MHz) 

cycles time 


Z8 
(12 MHz) 
cycles time 


Relative Performance 
MC6801 8051 


CRC 
Generation 


367 367 


139 139 


546 137 


546 91 


4.03 1.53 


Character 
Search 


687 687 


280 280 


1524 382 


1524 254 


2.70 1.10 


Computed 
GOTO 


110 110 


75 75 


228 57 


228 38 


2.89 1.97 


Shift Right 
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61 61 


46 46 
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577 577 


1924 481 


1924 321 


7.18 1.80 
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14 14 


4 4 


34 8.5 


34 5.7 


2.46 0.70 
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Port Bit 


8 8 


2 2 


10 2.5 

Overall 
Performance 


10 1.7 


4.71 1.18 
3.76 1.44 



Note: All times are given in microseconds. 



Table 3, Byte/Instruction/Time Comparison 
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SUMMARY 



The hardware of the three chips compared is very 
similar. The Z8611, however, has several advan- 
tages, the most important of which is its inter- 
rupt structure. It is more advanced than the 
interrupt structures of both the 8051 and the 
MC6801. Other advantages of the Z8611 over either 
the MC6801 or the 8051 include I/O facilities with 
parity detection and hardware handshake and a 
larger amount of internal ROM (the MC6801 has only 
2K bytes). 

Substantial differences are apparent with regard 
to software architecture. The addressing modes of 



the Z8611 are more flexible than those of either 
the MC6801 or the 8051. The Z8611 can use byte- 
saving addressing with working registers, and it 
has short external addresses for saving I/O lines. 
It can also provide for an external stack. The 
register architecture (as opposed to the accumu- 
lator architecture) of the Z8611 saves execution 
time and enhances programming speed by reducing 
the byte count. 

The Z8611 microcomputer stands out as the most 
powerful chip of the three, and concurrently, it 
is the easiest to program and configure. 
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The Interrupt Request Register (IRQ, R250) 
stores requests from the six possible inter- 
rupt sources (IRQ - IRQ 5 ) in the Z8600 series 
microcomputer. In addition to other func- 
tions, a hardware reset to the Z8600 disables 
the IRQ register and resets its request bits. 
Before the IRQ will register requests, it 
must first be enabled by executing an Enable 
Interrupts (El) instruction. Setting the 
Enable Interrupt bit in the Interrupt Mask 
Register (IMR, R251 ) is not an equivalent 
operation for this purpose; to enable the 
IRQ, an El instruction is required. The 
function of this El instruction is distinct 
from its task of globally enabling the inter- 
rupt system. Even in a pol led system where 
IRQ bits are tested In software, it is 
necessary to execute the El, 



The designer must ensure that unexpected and 
undesirable interrupt requests will not occur 
after the El is executed. One method of 
doing this is to reset all interrupt enable 
bits in the IMR for levels that are possible 
interrupt sources; the El instruction may 
then be safely executed. Once El is exe- 
cuted, the program may immediately execute a 
Disable Interrupts (Dl) instruction. The 
code necessary to perform these operations is 
as fol lows: 

RESET: LD IMR, #gXX !SET INTERRUPT MASK! 
El ! ENABLE GLOBAL INTER- 

RUPT, ENABLE IRQ! 

where XX has a in each bit position cor- 
responding to the interrupt level to be 
disabled. If all IMR bits are to be reset, a 
CLR IMR instruction may be used. 



EI INSTRUCTION- 



">> 



RESET 



I 



INTERRUPT REQUEST REG. 
(IRQ, R250) 



Q-0 RESET 



Z8600 



Figure 1 - IRQ Reset Functional Logic Diagram 



617-1881-0005 Reprinted with permission of Synertek, Inc. 1-29 



10/23/80 



12- Bit Addressing 
with the Z8 Family 




Zilog 



Application Brief 



January 1981 



12-BIT The Z8601 can manipulate data in four memory 

ADDRESSING spaces: internal program memory, internal 

WITH THE Z8600 register file, external program memory, and 
SERIES FAMILY external data memory. The internal register 
file is not discussed in this paper. Port 3 
may be configured optionally to provide a 
Data Memory ("DM) strobe that is used to 
select program and data memory. The Z8601 
generates another signal, Data Strobe (DS), 
that signals an external memory operation. DS 



is generated each time an address greater 
than 2047 is used. 



The Z8601 has 2K bytes of on-chip program 
memory. The user cannot directly access 
external memory in the address range of to 
2K since this address range is decoded as an 
internal address. The Z8600 accesses ex- 
ternal memory in the following manner: 



Table 1« Port Configured to Output A3-A15 



USER ADDRESS 


PHYSICAL MEMORY 


LOCATION 


DS 


ADDRESSES ON 
PORTS & 1 


DATA 


PROGRAM 


$0000-$07FF 
$0800-$FFFF 


NONE 
$0800-$FFFF 


$0000-$07FF 
$0800-$FFFF 


1 NTERNAL 
EXTERNAL 


INACTIVE 
ACTIVE 


0000-07FF 
0800-FFFF 



NOTE: The external physical addresses $0000-$07FF cannot be accessed. 
$FFFF $FFFF 





EXTERNAL 




EXTERNAL 






PROGRAM 




DATA 






MEMORY 




MEMORY 




$0800 








$0800 


$07FF 






$07FF 




INTERNAL 




NOT 






PROGRAM MEMORY 




ADDRESSABLE 




$0000 








$0000 
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With Port giving the high byte of address 
and Port 1 giving the low byte of address, a 
total of 126K bytes of memory can be ac- 
cessed: 2K bytes of on-chip ROM, 62K bytes 
of external data memory, and 62K bytes of 
external program memory. 



This scheme does not provide access to the 
external memory in the address range of to 
2K. To access memory in the to 2K range 
of external memory, the upper address nibble 
of Port is truncated and address locations 
4K to 6K are mapped into the to 2K ex- 
ternal memory range as follows: 



Table 2, Port Configured to Output A3-AJ1 



USER ADDRESS 


PHYSICAL MEMORY 


LOCATION 


DS 


ADDRESSES ON 
PORTS & 1 


DATA PROGRAM 


0000-07FF 
0800-OFFF 
1000-17FF 


NONE 0000-07FF 
0800-OFFF 0800-OFFF 
0000-07FF 0000-07FF 


1 NTERNAL 
EXTERNAL 
EXTERNAL 


INACTIVE 
ACTIVE 
ACTIVE 


0000-07FF 
0800-OFFF 
0000-07FF 



Using the above configuration, memory is 
accessable in the address range of to 6K, 
Higher addresses are indistinguishable from 
the to 6K address space, because the upper 
four address bits have not been programmed 
to appear on Port 0, 

The Z8600 can access up to 10K of memory 
using only 12 address lines. It can access 
2K of program memory on-chip, 4K of external 
data memory, and 4K of external program 
memory for a total of 10K, With only 12 
address lines, four lines are released in 
Port for I/O. 

To configure Port 3 to provide the Data 
Memory (DM) signal the following command is 
used: 



LD 



P3M,#(2)XXX10XXX 



The following instruction specifies Port 
as address lines Ag-A^ and Port 1 as 
address/data multiplexed lines AD -AD 7 . 



LD 



P01M,#(2)0XX10X1X 



The above Xs do not represent "don't care" 
states. These bits must be set or reset 
depending on the particular configuration in 
which the Z8600 is set. 

For medium-sized memory applications, the 
Z8600 can be configured to output address 
lines A Q -A 11 on Port 0, address/data multi- 
plexed lines ADq-AD 7 on Port 1, and DM on 
Port 3. In addition, the Z8600 can access a 
total of 10K bytes of memory. 
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INTRODUCTION The Zilog Z8600 UART microcomputer is a high- 
performance, single-chip device that incor- 
porates on-chip ROM, RAM, parallel I/O, 
serial I/O, and a baud rate generator. The 
UART is capable of ful l-duplex, asynchronous 
serial communication at nine standard 
software-selectable baud rates from 110 to 
19.2K baud; other nonstandard rates can also 
be obtained under software control. Odd 
parity generation and checking can also be 
selected. 



Three possible error conditions can occur 
during reception of serial data: framing 
error, parity error, and overrun error. A 
framing error condition occurs when a stop 
bit is not received at the proper time 
(Figure 1), This can result from noise in 
the data channel, causing erroneous detection 
of the previous start bit or lack of detec- 
tion of a properly transmitted stop bit. The 
Z8600 UART does not incorporate hardware 
framing error detection but does facilitate a 
simple, low-overhead software detection 
method • 







LSB 














MSB 


1 1 
I i 









1 


2 


3 


4 


5 


6 


7 


1 1 
L _J 




START PARITY 


STOP 


BIT DATA BITS (8) (IF BIT 


















ENABLED) 



Fig. 1 - Asynchronous Data Format 



METHOD In the middle of the stop bit time, the Z8600 
UART automatically posts a serial input 
interrupt request on IRQ3* The serial input 
can also be tested by reading Port 3 bit 
(P3q) as shown in Figure 2, Thus, within 
the interrupt service routine or polling 
loop, it is only necessary to test P3q in 
order to identify a framing error. If P3 Q is 
Low when IRQ-* goes High, a framing error con- 



dition exists and the following code is used 
to test this: 



P3, ##01 
Z, FERR 



! TEST FOR P30 = 1 ! 
ELSE FRAMING ERROR ! 



The execution time of this framing error test 
is only 5,5><(s at 8 MHz, In the worst case 
(19.2K baud), this would result in 1$ over- 
head. Only five program bytes are required. 




Ffg. 2 - Z8600 Serial Input Connection 



Z8 is a trademark of Zilog, Inc, 
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CONCLUSION While the Z8600 UART does not incorporate maximum penalty of \% at 19. 2K baud using no 

hardware framing error detection, this additional hardware and only five bytes of 

feature can be implemented in software with a program memory. 



Reprinted with permission of Synertek, Inc. 
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SECTION Introduction 

1 The Z8 is the first microcomputer to offer 

both a highly integrated microcomputer on a 
single chip and a fully expandable micropro- 
cessor for I/O-and memory-intensive applica- 
tions. The Z8 has two timer/counters, a UART, 
2K bytes internal ROM, and a 144-byte inter- 
nal register file including 124 bytes of RAM, 
32 bits of I/O, and 16 control and status reg- 
isters. In addition, the Z8 can address up to 
124K bytes of external program and data 
memory, which can provide full, memory- 
mapped I/O capability. 



This application note describes the important 
features of the Z8, with software examples that 
illustrate its power and ease of use. It is 
divided into sections by topic; the reader need 
not read each section seguentially, but may 
skip around to the sections of current interest. 

It is assumed that the reader is familiar with 
the Z8 and its assembly language, as 
described in the following documents: 

■ Z8 Technical Manual (03-3047-02) 

■ Z8 PLZ/ASM Assembly Language Program- 
ming Manual (03-3023-02) 



SECTION 

2 



Accessing Register Memory 

The Z8 register space consists of four I/O 
ports, 16 control and status registers, and 124 
general-purpose registers. The general- 
purpose registers are RAM areas typically used 
for accumulators, pointers, and stack area. 
This section describes these registers and how 
they are used. Bit manipulation and stack 
operations affecting the register space are 
discussed in Sections 4 and 5, respectively. 

2.1 Registers and Register Pairs. The Z8 sup- 
ports 8-bit registers and 16-bit register pairs. 
A register pair consists of an even-numbered 
register concatenated with the next higher 
numbered register (%00 and %01, %02 and 
%03, ... %7E and %7F, %F0 and %F1, ... 
%FE and %FF). A register pair must be 
addressed by reference to the even-numbered 
register. For example, 

%F1 and %F2 is not a valid register pair; 
%F0 and %F1 is a valid register pair, 
addressed by reference to %F0. 

Register pairs may be incremented (INCW) 
and decremented (DECW) and are useful as 
pointers for accessing program and external 
data memory. Section 3 discusses the use of 
register pairs for this purpose. 



Any instruction which can reference or 
modify an 8-bit register can do so to any of the 
144 registers in the Z8, regardless of the 
inherent nature of that register. Thus, I/O 
ports, control, status, and general-purpose 
registers may all be accessed and manipulated 
without the need for special-purpose instruc- 
tions. Similarly, instructions which reference 
or modify a 16-bit register pair can do so to 
any of the valid 72 register pairs. The only 
exceptions to this rule are: 

■ The DJNZ (decrement and jump if non-zero) 
instruction may successfully operate on the 
general-purpose RAM registers (%04-%7F) 
only. 

■ Six control registers are write-only registers 
and therefore, may be modified only by 
such instructions as LOAD, POP, and 
CLEAR. Instructions such as OR and AND 
reguire that the current contents of the 
operand be readable and therefore will not 
function properly on the write-only 
registers. These registers are the following: 
the timer/counter prescaler registers PREO 
and PRE1, the port mode registers P01M, 
P2M, and P3M, the interrupt priority 
register IPR. 
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2. Accessing 2.2 Register Pointer. Within the register 
Register addressing modes provided by the Z8, a regis- 

Memory ter may be specified by its full 8-bit address 

(Continued) (0-%7F, %F0-%FF) or by a short 4-bit 
address. In the latter case, the register is 
viewed as one of 16 working registers with- 
in a working register group. Such a group 
must be aligned on a 16-byte boundary and is 
addressed by Register Pointer RP (%FD). As 
an example, assume the Register Pointer con- 
tains %70, thus pointing to the working reg- 
ister group from %70 to %7F. The LD instruc- 
tion may be used to initialize register %76 to 
an immediate value in one of two ways: 



LD %76J 



or 
LD R6,#l 



!8-bit register address is given 
by instruction (3 byte instruc- 
tion)! 

!4-bit working register address 
is given by instruction; 4-bit 
working register group 
address is given by Register 
Pointer (2 byte instruction)! 



The address calculation for the latter case 
is illustrated in Figure 1 . Notice that 4-bit 
working-register addressing offers code com- 
pactness and fast execution compared to its 
8-bit counterpart. 

To modify the contents of the Register 
Pointer, the Z8 provides the instruction 

SRP #value 

Execution of this instruction will load the 
upper four bits of the Register Pointer; the 
lower four bits are always set to zero. Although 
a load instruction such as 

LD RP,#value 

could be used to perform the same function, 
SRP provides execution speed (six vs. ten 
cycles) and code space (two vs. three bytes) 
advantages over the LD instruction. The 
instruction 

SRP #%70 

is used to set the Register Pointer for the above 
example. 



I 1 1 1 I ft ft 9 



iNSTRuCTiON 
(LD R6,#1) 



110 



M 1 ° °J [ 



000000011 



1110 11 J 



Figure 1. Address Calculation Using the Register Pointer 



2.3 Context Switching. A typical function 
performed during an interrupt service routine 
is context switching. Context switching refers 
to the saving and subsequent restoring of the 
program counter, status, and registers of the 
interrupted task. During an interrupt machine 
cycle, the Z8 automatically saves the Program 
Counter and status flags on the stack. It is the 
responsibility of the interrupt service routine to 
preserve the register space. The recommended 
means to this end is to allocate a specific por- 
tion of the register file for use by the service 
routine. The service routine thus preserves the 
register space of the interrupted task by avoid- 
ing modification of registers not allocated as its 
own. The most efficient scheme with which to 
implement this function in the Z8 is to allocate 
a working register group (or portion thereof) to 
the interrupt service routine. In this way, the 
preservation of the interrupted task's registers 
is solely a matter of saving the Register Pointer 
on entry to the service routine, setting the 
Register Pointer to its own working register 
group, and restoring the Register Pointer prior 
to exiting the service routine. For example, 



assume such a register allocation scheme has 
been implemented in which the interrupt ser- 
vice routine for IRQO may access only working 
register Group 4 (registers %40-%4F). The 
service routine for IRQO should be headed by 
the code sequence: 

PUSH RP ! preserve Register Pointer of 

interrupted task! 
SRP #%40 ! address working register 

group 4! 

Before exiting, the service routine should 
execute the instruction 

POP RP 

to restore the Register Pointer to its entry 
value. 

It should be noted that the technique 
described above need not be restricted to 
interrupt service routines. Such a technique 
might prove efficient for use by a subroutine 
requiring intermediate registers to produce its 
outputs. In this way, the calling task can 
assume that its environment is intact upon 
return from the subroutine. 
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2. Accessing 2.4 Addressing Mode. The Z8 provides three 

Register addressing modes for accessing the register 

Memory space: Direct Register, Indirect Register, and 

(Continued) Indexed. 

2.4.1 Direct Register Addressing. This 
addressing mode is used when the target regis- 
ter address is known at assembly time. Both - 
long (8-bit) register addressing and short 
(4-bit) working register addressing are sup- 
ported in this mode. Most instructions sup- 
porting this mode provide access to single 
8-bit registers. For example: 

LD %FE,#HI STACK 

!load register %FE (SPH) with 

the upper 8-bits of the label 

STACK! 
AND 0,MASK_REG 

!AND register with register 

named MASK_REG! 
OR 1,R5 !OR register 1 with working 

register 5! 

Increment word (INCW) and decrement 
word (DECW) are the only two Z8 instructions 
which access 16-bit operands. These instruc- 
tions are illustrated below for the direct reg- 
ister addressing mode. 

INCW RRO ! increment working register 
pair RO, Rl: 
Rl ««- Rl + 1 
RO ^ RO + carry! 

DECW %7E 

{decrement working register 
pair %7E, %7F: 
%7F ^ %7F - 1 
%7E *- %7E - carry! 

Note that the instruction 

INCW RR5 

will be flagged as an error by the assembler 
(RR5 not even- numbered). 

2.4.2 Indirect Register Addressing. In this 
addressing mode, the operand is pointed to by 
the register whose 8-bit register address or 
4-bit working register address is given by the 
instruction. This mode is used when the target 
register address is not known at assembly time 
and must be calculated during program execu- 
tion. For example, assume registers %60-%7F 
contain a buffer for output to the serial line via 

repetitive calls to procedure SERIAL OUT. 

SERIAL OUT expects working register to 

hold the output character. The following 
instructions illustrate the use of the indirect 
addressing mode to accomplish this task: 

LD Rl,#%20 

! working register 1 is the byte 
counter: output %20 bytes! 



LD R2,#%60 

! working register 2 is the buf- 
fer pointer register! 
out again: 

LD R0,@R2 

!load into working register 
the byte pointed to by working 
register 2! 

INC R2 ! increment pointer! 

CALL SERIAL_OUT 

! output the byte! 

DJNZ Rl,out_again 

!loop till done! 

Indirect addressing may also be used for 
accessing a 16-bit register pair via the INCW 
and DECW instructions. For example, 

INCW @R0 ! increment the register pair 

whose address is contained in 
working register 0! 

DECW @%7F 

! decrement the register pair 
whose address is contained in 
register %7F! 

The contents of registers RO and %7F should 
be even numbers for proper access; when 
referencing a register pair, the least significant 
address bit is forced to the appropriate value 
by the Z8. However, the register used to point 
to the register pair need not be an even- 
numbered register. 

Since the indirect addressing mode permits 
calculation of a target address prior to the 
desired register access, this mode may be used 
to simulate other, more complex addressing 
modes. For example, the instruction 

SUB 4,BASE(R5) 

requires the indexed addressing mode which is 
not directly supported by the Z8 SUBtract 
instruction. This instruction can be simulated 
as follows: 

LD R6,#BASE 

! working register 6 has the 

base address! 
ADD R6,R5 {calculate the target address! 
SUB 4,@R6 !now use indirect addressing to 

perform the actual subtract! 

Any available register or working register 
may be used in place of R6 in the 
above example. 

2.4.3 Indexed Addressing. The indexed 
addressing mode is supported by the load 
instruction (LD) for the transference of bytes 
between a working register and another regis- 
ter. The effective address of the latter register 
is given by the instruction which is offset by 
the contents of a designated working (index) 
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2. Accessing 

Register 

Memory 

(Continued) 



register. This addressing mode provides 
efficient memory usage when addressing 
consecutive bytes in a block of register 
memory, such as a table or a buffer. The 
working register used as the index in 
the effective address calculation can 
serve the additional role of counter for 
control of a loop's duration. 

For example, assume an ASCII character 
buffer exists in register memory starting at 
address BUF for LENGTH bytes. In order 
to determine the logical length of the char- 
acter string, the buffer should be scanned 
backward until the first nonoccurrence of a 
blank character. The following code 
seguence may be used to accomplish 
this task: 

LD R0,#LENGTH 

! length of buffer! 
! starting at buffer end, look for 
1st non-blank! 
loop: 

LD R1,BUF-1(R0) 
CP Rl,#" 
IR ne, found 

'found non-blank! 
DJNZ R0,loop 

!look at next! 
all__blanks: ilength = 0! 
found: 

5 instructions 

12 bytes 

1.5 /xs overhead 

10.5 fis (average) per character tested 

At labels u all blanks" and u found," R0 

contains the length of the character 
string. These labels may refer to the same 
location, but they are shown separately for 
an application where special processing is 
reguired for a string of zero length. To per- 
form this task without indexed address- 
ing would reguire a code seguence 
such as: 



LD R1,#BUF + LENGTH -1 
LD R0,#LENGTH 

(starting at buffer end, look for 
1st non-blank! 



loopl: 
CP 
JR 



@R1,#' ' 
ne, found 1 

! found non-blank! 
DEC Rl !dec pointer! 

DJNZ R0, loopl 

!are we done?! 
all_blanksl: Ilength = 0! 
foundl: 

6 instructions 

13 bytes 

3 /is overhead 

9.5 fis (average) per character tested 

The latter method reguires one more byte of 
program memory than the former, but is faster 
by four execution cycles (1 /us) per character 
tested. 

As an alternate example, assume a buffer 
exists as described above, but it is desired to 
scan this buffer forward for the first occur- 
rence of an ASCII carriage return. The follow- 
ing illustrates the code to do this: 



LD 


R0,#- LENGTH 




! starting at buffer start, look for 




1st carriage return ( = %0D)! 


next: 




LD 


rl,BUF + LENGTH(RO) 


CP 


R1,#%0D 


JR 


eg,cr ifound it! 


INC 


R0 ! update counter/index! 


JR 


nz,next 




!try again! 



ADD ROJLENGTH 

!R0 has length to CR! 
7 instructions 
16 bytes 
1.5 /*s overhead 
12 [is (average) per character tested 



SECTION Accessing Program and External Data 

O Memory 

In a single instruction, the Z8 can transfer a 
byte between register memory and either pro- 
gram or external data memory. Load Constant 
(LDC) and Load Constant and Increment 
(LDCI) reference program memory; Load 
External (LDE) and Load External and Incre- 
ment (LDEI) reference external data memory. 
These instructions reguire that a working 
register pair contain the address of the byte in 
either program or external data memory to be 
accessed by the instruction (indirect working 
register pair addressing mode). The register 
byte operand is specified by using the direct 
working register addressing mode in LDC and 



LDE or the indirect working register address- 
ing mode in LDCI and LDEI. In addition to 
performing the designated byte transfer, LDCI 
and LDEI automatically increment both the 
indirect registers specified by the instruction. 
These instructions are therefore efficient for 
performing block moves between register and 
either program or external data memory. Since 
the indirect addressing mode is used to specify 
the operand address within program or exter- 
nal data memory, more complex addressing 
modes may be simulated as discussed earlier 
in Section 2.4.2. For example, the instruction 

LDC R3,BASE(R2) 

reguires the indexed addressing mode, where 
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3. Accessing BASE is the base address of a table m program 
Program and memory and R2 contains the offset from table 
External Data start to the desired table entry. The following 
Memory code sequence simulates this instruction with 

(Continued) the use of two additional registers (RO and Rl 
in this example). 

LD R0,#HI BASE 
LD Rl,#LOBASE 

!RR0 has table start address! 
ADD R1,R2 
ADC R0,#0 

!RR0 has table entry address! 
LDC R3,@RR0 

!R3 has the table entry! 

3.1 Configuring the Z8 for I/O Applications 
vs. Memory Intensive Applications. The Z8 

offers a high degree of flexibility in memory 
and I/O intensive applications. Thirty-two port 
bits are provided of which 16, 12, eight, or 
zero may be configured as address bits to 
external memory. This allows for addressing of 
62K, 4K or 256 bytes of external memory, 
which can be expanded to 124K, 8K, or 512 
bytes if the Data Memory Select output (DM) is 
used to distinguish between program and data 
memory accesses. The following instructions 
illustrate the code sequence required to con- 
figure the Z8 with 12 external addressing lines 
and to enable the Data Memory Select output. 



LD P01M,#%(2)00010010 

ibit 3-4: enable AD -AD 7 ; 
bit 0-1: enable A 8 -An! 

LD P3M,#%( 2)0000 1000 

!bit 3-4: enable DM! 

The two bytes following the mode selection of 
ports and 1 should not reference external 
memory due to pipelining of instructions within 
the Z8. Note that the load instruction to P3M 
satisfies this requirement (providing that it 
resides within the internal 2K bytes of 
memory). 

3.2 LDC and LDE. To illustrate the use of the 

Load Constant (LDC) and Load External (LDE) 
instructions, assume there exists a hardware 
configuration with external memory and Data 
Memory Select enabled. The following module 
illustrates a program for tokenizmg an ASCII 
input buffer. The program assumes there is a 
list of delimiters (space, comma, tab, etc.) in 
program memory at address DELIM for 
COUNT bytes (accessed via LDC) and that an 
ASCII input buffer exists in external data 
memory (accessed via LDE). The program 
scans the input buffer from the current location 
and returns the start address of the next token 
(i.e. the address of the first nondehmiter 
found) and the length of that token (number of 
characters from token start to next delimiter). 



Z8ASM 
LOC 



2.0 
OBJ CODE 



P 0000 20 
P 0003 2E 



P 0006 



3B 
0A 



2C 
0D 



STMT SOURCE STATEMENT 

1 SCAN MODULE 

2 CONSTANT 

3 COUNT := 

4 GLOBAL 
5 
6 DELIM 



P 0006 B0 E2 



p 


0008 


82 


30 


p 


000A 


A0 


E0 


p 


oooc 


D6 


002E' 


p 


000F 


FD 


0015' 


p 


0012 


8D 


0018' 


p 


0015 


8D 


0008' 



$SECTI0N PROGRAM 
ARRAY [COUNT BYTE] 



%0k , %0D] 



9 scan 



PROCEDURE 



10 !*********#*#*#**#*#*******#*******#**###**##*##**#*## 



Purpose 
Input = 



11 

12 

13 

14 

15 

16 

17 

18 Output 

19 

20 

21 

22 

23 

24 



To find the next token within an 
ASCII buffer. 

RR0 = address of current location 

within input buffer in external 
memory. 

RR4 = address of start of next token 
RR0 = address of new token's ending 

delimiter 
R2 r length of token 
R3 = ending delimiter 
R6,R7,R8,R9 destroyed 



25 #*#*####*#**##***###*#*###*##*#*##*#*#**##*##*#*##### I 

26 ENTRY 

27 clr R2 Unit, length counter! 

28 DO 

29 LDE R3,@RR0 !get byte from input buffer! 

30 incw RR0 !increment pointer! 

31 call check !look for non-delimiter! 

32 IF C THEN 

33 EXIT Jfound token start! 

34 FI 

35 OD 
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3. Accessing 
Program and 
External Data 
Memory 

(Continued) 



0018 48 
001A 58 

001C 2E 
001D 82 
001F D6 
0022 7D 
0025 8D 



P 0028 A0 
P 002A 8D 



P 002D AF 
P 002E 



P 002E 



0034 C2 
0036 A0 
003$ A2 
003A 6B 
003C 8A 
003E DF 



P 003F AF 
P 0040 



E0 
E1 



30 

002E ! 
0028' 
002D' 

E0 
001C 



P 002E 6C 00* 
P 0030 7C 00* 

P 0032 8C 06 



96 
E6 
93 
03 
F6 



36 
37 
38 
39 
40 
41 
42 
43 
44 
45 
46 
47 
48 
49 
50 

51 
52 
53 
54 
55 
56 
57 
58 
59 
60 
61 
62 
63 
64 
65 
66 
67 
68 
69 
70 
71 
72 
73 
74 
75 
76 
77 
78 
79 
80 
81 
82 
83 
84 
85 



END 



Id 

Id 
DO 

inc 

LDE 

call 

IF NC 
EXIT 

FI 

incw 
OD 

ret 
scan 



R4,R0 
R5,R1 



!RR4 = token starting addr! 



R2 line, length counter! 
R3,@RR0 !get next input byte! 
check !look for delimiter! 
THEN 

!found token end! 



RRO 



!point to next byte! 



check PROCEDURE 
txxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

Purpose = compare current character with 
delimiter table until table 
end or match found 

input = DELIM = start address of table 
COUNT = length of that table 
R3 = byte to be scrutinized 

output = Carry flag = 1 => input byte 

is not a delimiter (no match found) 

Carry flag = => input byte 
is a delimiter (match found) 
R6,R7,R8,R9 destroyed 

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXI 

ENTRY 

Id R6,//HI DELIM 
Id R7,#L0 DELIM 



here: 



bye: 

END 
END 



Id 

LDC 

incw 

cp 

jr 

djnz 

scf 



ret 

check 

SCAN 



!RR6 points to 
delimiter list! 
R8, //COUNT !R8 = length of list! 

R9,@RR6 !get table entry! 
RR6 ! point to next entry! 

R9,R3 !R3 = delimiter?! 

eq,bye !yes. carry = 0! 

R8,here !next entry! 

!table done. R3 
not a delimiter! 



ERRORS 
ASSEMBLY COMPLETE 



27 instructions 

58 bytes 

Execution time is a function of the number of leading delimiters 
before token start (x) and the number of characters in the 
token (y): 123 fis overhead + 59x fis + 102y fis 
(average) per token 



3.3 LDCI. A common function performed in Z8 
applications is the initialization of the register 
space. The most obvious approach to this func- 
tion is the coding of a sequence of "load 
register with immediate value" instructions 
(each occupying three program bytes for a 



register or two program bytes for a working 
register). This approach is also the most effi- 
cient technique for initializing less than eight 
consecutive registers or 14 consecutive work- 
ing registers. For a larger register block, the 
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3. Accessing LDCI instruction provides an economical 
Program and means of initializing consecutive registers from 
External Data an initialization table in program memory. The 
Memory following code excerpt illustrates this tech- 

( Continued) nique of initializing control registers %F2 

through %FF from a 14-byte array (INIT tab) 

in program memory: 

SRP #%00 

!RP not %F0! 
LD R6,#HI INIT_tab 
LD R7,#LO INIT_tab 
LD R8,#%F2 

list reg to be initialized! 
LD R9,#14 

! length of register block! 
loop: 

LDCI @R8,@RR6 

!load a register from the 

init table! 
DJNZ R9,loop 

{continue till done! 
7 instructions 
14 bytes 
7.5 /is overhead 
7.5 /is per register initialized 



3.4 LDEI. The LDEI instruction is useful for 
moving blocks of data between external and 
register memory since auto- increment is per- 
formed on both indirect registers designated 
by the instruction. The following code excerpt 
illustrates a register buffer being saved at 
address %40 through %60 into external 
memory at address SAVE: 

LD R10,#HI SAVE 

! external memory! 
LD R11JLOSAVE 

! address! 
LD R8,#%40 

! starting register! 
LD R9,#%21 

.'number of registers to save in 

external data memory! 
loop: 

LDEI @RR10,@R8 

!init a register! 
DJNZ R9,loop 

! until done! 
6 instructions 
12 bytes 
6 jis overhead 
7.5 jus per register saved 



SECTION 
4 



Bit Manipulations 

Support of the test and modification of an 
individual bit or group of bits is required by 
most software applications suited to the Z8 
microcomputer. Initializing and modifying the 
Z8 control registers, polling interrupt requests, 
manipulating port bits for control of or com- 
munication with attached devices, and manipu- 
lation of software flags for internal control pur- 
poses are all examples of the heavy use of bit 
manipulation functions. These examples illus- 
trate the need for such functions in all areas of 
the Z8 register space. These functions are sup- 
ported in the Z8 primarily by six instructions: 

■ Test under Mask (TM) 

■ Test Complement under Mask (TCM) 

■ AND 

■ OR 

■ XOR 

■ Complement (COM) 

These instructions may access any Z8 register, 
regardless of its inherent type (control, I/O, or 
general purpose), with the exception of the six 
write-only control registers (PREO, PRE1, 
P01M, P2M, P3M, IPR) mentioned earlier in 
Section 2.1. Table 1 summarizes the function 
performed on the destination byte by each of 
the above instructions. All of these instruc- 
tions, with the exception of COM, require a 
mask operand. The "selected" bits referenced 
in Table 1 are those bits in the destination 
operand for which the corresponding mask bit 
is a logic 1. 



Opcode 



Use 



TM To test selected bits for logic 

TCM To test selected bits for logic 1 

AND To reset all but selected bits to logic 

OR To set selected bits to logic 1 

XOR To complement selected bits 

COM To complement all bits 

Table 1 . Bit Manipulation Instruction Usage 

The instructions AND, OR, XOR, and COM 
have functions common to today's micro- 
processors and therefore are not described in 
depth here. However, examples of the use of 
these instructions are laced throughout the 
remainder of this document, thus giving an 
integrated view of their uses in common func- 
tions. Since they are unique to the Z8, the 
functions of Test under Mask and Test Comple- 
ment under Mask, are discussed in more detail 
next. 

4.1 Test under Mask (TM). The Test under 
Mask instruction is used to test selected bits for 
logic 0. The logical operation performed is 

destination AND source 

Neither source nor destination operand is 
modified; the FLAGS control register is the 
only register affected by this instruction. The 
zero flag (Z) is set if all selected bits are logic 
0; it is reset otherwise. Thus, if the selected 
destination bits are either all logic 1 or a com- 
bination of Is and 0s, the zero flag would be 
cleared by this instruction. The sign flag (S) is 
either set or reset to reflect the result of the 
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4. Bit 
Manipu- 
lations 

(Continued) 



AND operation; the overflow flag (V) is always 
reset. All other flags are unaffected. Table 2 
illustrates the flag settings which result from 
the TM instruction on a variety of source and 
destination operand combinations. Note that a 
given TM instruction will never result in both 
the Z and S flags being set. 

4.2 Test Complement under Mask. The Test 
Complement under Mask instruction is used to 
test selected bits for logic 1 . The logical opera- 
tion performed is 

(NOT destination) AND source. 



As in Test under Mask, the FLAGS control 
register is the only register affected by this 
operation. The zero flag (Z) is set if all selected 
destination bits are 1; it is reset otherwise. The 
sign flag (S) is set or reset to reflect the result 
of the AND operation; the overflow flag (V) is 
always reset. Table 3 illustrates the flag set- 
tings which result from the TCM instruction on 
a variety of source and destination operand 
combinations. As with the TM instruction, a 
given TCM instruction will never result in both 
the Z and S flags being set. 



Destination 



Source 



Flags 



Destination 



Source 



Flags 



(binary) 
10001100 
01111100 
10001100 
11111100 
00011000 
01000000 



(binary) 


Z 


s 


V 


01110000 


1 








01110000 











11110000 





1 





11110000 





1 





10100001 


1 








10100001 


1 









(binary) 
10001100 
01111100 
10001100 
11111100 
00011000 
01000000 



(binary) 


Z 


s 


V 


01110000 











01110000 


1 








11110000 











11110000 


1 








10100001 





1 





10100001 





1 






Table 2. Effects of the TM Instruction 



Table 3. Effects of the TCM Instruction 



SECTION 

5 



Stack Operations 

The Z8 stack resides within an area of data 
memory (internal or external). The current 
address in the stack is contained in the stack 
pointer, which decrements as bytes are pushed 
onto the stack, and increments as bytes are 
popped from it. The stack pointer occupies two 
control register bytes (%FE and %FF) in the 
Z8 register space and may be manipulated like 
any other register. The stack is useful for 
subroutine calls, interrupt service routines, 
and parameter passing and saving. Figure 2 
illustrates the downward growth of a stack as 
bytes are pushed onto it. 

5.1 Internal vs. External Stack. The location 
of the stack in data memory may be selected to 
be either internal register memory or external 
data memory. Bit 2 of control register P01M 
(%F8) controls this selection. Register pair 
SPH (%FE), SPL (%FF) serves as the stack 
pointer for an external stack. Register SPL is 
the stack pointer for an internal stack. In the 



x SP — 




SP — 




SP — 




x-1 




81 


m 


x-2 






PC LOW 


x-3 






PC mm 


x-4 










INITIAL 
STATE 


FOLLOWING 
PUSH R1 




FOLLOWING 
CALL 



latter configuration, SPH is available for use as 
a data register. The following illustrates a code 
sequence that initializes external stack opera- 
tions: 

LD P01M,#%(2)00000000 

!bit 2: select external stack! 
LD SPH,#HI STACK 
LD SPL,#LO STACK 

5.2 CALL. A subroutine call causes the cur- 
rent Program Counter (the address of the byte 
following the CALL instruction) to be pushed 
onto the stack. The Program Counter is loaded 
with the address specified by the CALL 
instruction. This address may be a direct 
address or an indirect register pair reference. 
For example, 

LABEL 1: CALL %4F98 

! direct addressing: PC is 
loaded with the hex value 
4F98; 

address LABEL 1 + 3 is pushed 
onto the stack! 

LABEL 2: CALL @RR4 

{indirect addressing: PC is 
loaded with the contents of 
working register pair R4, R5; 
address LABEL 2 + 2 is pushed 
onto the stack! 



Figure 2. Growth of a Stack 
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5. Stack LABEL 3: CALL @%7E 

Operations ! indirect addressing: PC is 

(Continued) loaded with the contents of 

register pair %7E ; %7F; 

address LABEL 3 + 2 is pushed 

onto the stack! 

5.3 RET. The return (RET) instruction causes 
the top two bytes to be popped from the stack 
and loaded into the Program Counter. Typi- 
cally, this is the last instruction of a subroutine 
and thus restores the PC to the address follow- 
ing the CALL to that subroutine. 

5.4 Interrupt Machine Cycle. During an inter- 
rupt machine cycle, the PC followed by the 
status flags is pushed onto the stack. (A more 
detailed discussion of interrupt processing is 
provided in Section 6.) 

5.5 IRET. The interrupt return (IRET) instruc- 
tion causes the top byte to be popped from the 
stack and loaded into the status flag register, 
FLAGS (%FC), the next two bytes are then 
popped and loaded into the Program Counter. 
In this way, status is restored and program 
execution continues where it had left off when 
the interrupt was recognized. 

5.6 PUSH and POP. The PUSH and POP 
instructions allow the transfer of bytes between 



the stack and register memory, thus providing 
program access to the stack for saving and 
restoring needed values and passing 
parameters to subroutines. 

Execution of a PUSH instruction causes the 
stack pointer to be decremented by 1 ; the 
operand byte is then loaded into the location 
pointed to by the decremented stack pointer. 
Execution of a POP instruction causes the byte 
addressed by the stack pointer to be loaded 
into the operand byte; the stack pointer is then 
incremented by 1. In both cases, the operand 
byte is designated by either a direct register 
address or an indirect register reference. For 
example: 

PUSH Rl [direct address: push working 
register 1 onto the stack! 

POP 5 ! direct address: pop the top 

stack byte into register 5! 

PUSH @R4 ! indirect address: pop the top 
stack byte into the byte 
pointed to by working reg- 
ister 4! 

PUSH @17 ! indirect address: push onto 
the stack the byte pointed to 
by register 17! 



SECTION Interrupts 

g The Z8 recognizes six different interrupts 

from four internal and four external sources, 
including internal timer/counters, serial I/O, 
and four Port 3 lines. Interrupts may be indi- 
vidually or globally enabled/disabled via Inter- 
rupt Mask Register IMR (%FB) and may be 
prioritized for simultaneous interrupt resolution 
via Interrupt Priority Register IPR (%F9). 
When enabled, interrupt reguest processing 
automatically vectors to the designated service 
routine. When disabled, an interrupt reguest 
may be polled to determine when processing is 
needed. 

6.1 Interrupt Initialization. Before the Z8 can 
recognize interrupts following RESET, some 
initialization tasks must be performed. The ini- 
tialization routine should configure the Z8 
interrupt requests to be enabled/disabled, as 
required by the target application and 
assigned a priority (via IPR) for simultaneous 
enabled-mterrupt resolution. An interrupt 
request is enabled if the corresponding bit in 
the IMR is set ( = 1) and interrupts are 
globally enabled (bit 7 of IMR = 1). An inter- 
rupt request is disabled if the corresponding 
bit in the IMR is reset ( = 0) or interrupts are 
globally disabled (bit 7 of IMR = 0). 

A RESET of the Z8 causes the contents of the 
Interrupt Request Register IRQ (%FA) to be 
held to zero until the execution of an EI 



instruction. Interrupts that occur while the Z8 
is in this initial state will not be recognized, 
since the corresponding IRQ bit cannot be set. 
The EI instruction is specially decoded by the 
Z8 to enable the IRQ; simply setting bit 7 of 
IMR is therefore not sufficient to enable inter- 
rupt processing following RESET. However, 
subsequent to this initial EI instruction, inter- 
rupts may be globally enabled either by the 
instruction 

EI lenable interrupts! 

or by a register manipulation instruction 
such as 

OR IMR,#%80 

To globally disable interrupts, execute the 
instruction 



DI 



Idisable interrupts! 



This will cause bit 7 of IMR to be reset. 

Interrupts must be globally disabled prior to 
any modification of the IMR, IPR or enabled 
bits of the IRQ (those corresponding to 
enabled interrupt requests), unless it can be 
guaranteed that an enabled interrupt will not 
occur during the processing of such instruc- 
tions. Since interrupts represent the occur- 
rence of events asynchronous to program exe- 
cution, it is highly unlikely that such a 
guarantee can be made reliably. 
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6. Interrupts 6.2 Vectored Interrupt Processing. Enabled 
(Continued) interrupt requests are processed in an 

automatic vectored mode in which the inter- 
rupt service routine address is retrieved from 
within the first 12 bytes of program memory. 
When an enabled interrupt request is 
recognized by the Z8, the Program Counter is 
pushed onto the stack (low order 8 bits first, 
then high-order 8 bits) followed by the FLAGS 
register (#%FC). The corresponding interrupt 
request bit is reset in IRQ, interrupts are 
globally disabled (bit 7 of IMR is reset), and 
an indirect jump is taken on the word in loca- 
tion 2x, 2x + 1 (x = interrupt request number, 
0<x<5). For example, if the bytes at 
addresses %0004 and %0005 contain %05 and 
%78 respectively, the interrupt machine cycle 
for IRQ2 will cause program execution to con- 
tinue at address %0578. 

When interrupts are sampled, more than one 
interrupt may be pending. The Interrupt Prior- 
ity Register (IPR) controls the selection of the 
pending interrupt with highest priority. While 
this interrupt is being serviced, a higher- 
priority interrupt may occur. Such interrupts 



may be allowed service within the current 
interrupt service routine (nested) or may be 
held until the current service routine is com- 
plete (non-nested). 

To allow nested interrupt processing, inter- 
rupts must be selectively enabled upon entry 
to an interrupt service routine. Typically, only 
higher-priority interrupts would be allowed to 
nest within the current interrupt service. To do 
this, an interrupt routine must "know" which 
interrupts have a higher priority than the cur- 
rent interrupt request. Selection of such nest- 
ing priorities is usually a reflection of the 
priorities established in the Interrupt Priority 
Register (IPR). Given this data, the first 
instructions executed in the service routine 
should be to save the current Interrupt Mask 
Register, mask off all interrupts of lower and 
equal priority, and globally enable interrupts 
(EI). For example, assume that service of inter- 
rupt requests 4 and 5 are nested within the ser- 
vice of interrupt request 3. The following illus- 
trates the code required to enable IRQ4 
and IRQ5: 



CONSTANT 

INT_MASK_3 : = %(2) 001 10000 

GLOBAL 

IRQ3_service PROCEDURE ENTRY 

! service routine for IRQ3! 

PUSH IMR !save Interrupt Mask Register! 

! interrupts were globally disabled during the interrupt 
machine cycle - no DI is needed prior to modification of IMR! 
AND IMR,#INT__MASK_3 ! disable all but IRQ4 & 5! 

EI 
!...! ! service interrupt! 

! interrupts are globally enabled now — must disable them prior to 
modification of IMR! 
DI 

POP IMR ! restore entry IMR! 

IRET 
END IRQ3_service 



Note that IRQ4 and IRQ5 are enabled by the 
above sequence only if their respective IMR 
bits = 1 on entry to IRQ3 service. 

The service routine for an interrupt whose 
processing is to be completed without interrup- 
tion should not allow interrupts to be nested 
within it. Therefore, it need not modify the 
IMR, since interrupts are disabled automati- 
cally during the interrupt machine cycle. 

The service routine for an enabled interrupt 
is typically concluded with an IRET instruc- 
tion, which restores the FLAGS register and 
Program Counter from the top of the stack and 
globally enables interrupts. To return from an 
interrupt service routine without re-enabling 



interrupts, the following code sequence could 
be used: 

POP FLAGS 

! FLAGS «•- @SP! 

RET !PC <*- @SP! 

This accomplishes all the functions of IRET, 
except that IMR is not affected. 

6.3 Polled Interrupt Processing Disabled 
interrupt requests may be processed in a 
polled mode, in which the corresponding bits 
of the Interrupt Request Register (IRQ) are 
examined by the software. When an interrupt 
request bit is found to be a logic 1 , the inter- 
rupt should be processed by the appropriate 
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6. Interrupts service routine. During such processing, the 
(Continued) interrupt request bit in the IRQ must be 

cleared by the software in order for subsequent 
interrupts on that line to be distinguished from 
the current one. If more than one interrupt 
request is to be processed in a polled mode, 
polling should occur in the order of estab- 



lished priorities. For example, assume that 
IRQO, IRQ1, and IRQ4 are to be polled and 
that established priorities are, from high to 
low, IRQ4, IRQO, IRQ1. An instruction 
sequence like the following should be used to 
poll and service the interrupts: 



Ipoll interrupt inputs here! 

TCM IRQ, #%(2)00010000 

JR NZ, TESTO 

CALL IRQ4_service 

TESTO: TCM IRQ, #%(2)00000001 

IR NZ, TEST1 

CALL IRQO_service 

TEST1: TCM IRQ, #%(2)00000010 

JR NZ, DONE 

CALL IRQl_service 

DONE: !...! 

IRQ4_service PROCEDURE 
!...! 

AND IRQ, #%(2)1 11011 11 

RET 
END IRQ4__service 



IRQO service 

AND 

RET 
END IRQ0_service 

IRQ1 service 

! . . . ! 
AND 
!...! 
RET 

END IRQl_service 

I I 



PROCEDURE 

IRQ, #%(2)1 11111 10 

PROCEDURE 

IRQ, #%(2)11111101 



ENTRY 



ENTRY 



ENTRY 



IIRQ4 need service?! 



lyes! 

!IRQ0 need service?! 

!no! 



lyes! 

IIRQ1 need service?! 

!no! 

!yes! 



! clear IRQ4! 



{clear IRQO! 



! clear IRQ1! 



SECTION 
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Timer/Counter Functions 

The Z8 provides two 8-bit timer/counters, Tq 
and T\, which are adaptable to a variety of 
application needs and thus allow the software 
(and external hardware) to be relieved of the 
bulk of such tasks. Included in the set of such 
uses are: 

■ Interval delay timer 

■ Maintenance of a time-of-day clock 

■ Watch-dog timer 

■ External event counting 

■ Variable pulse tram output 

■ Duration measurement of external event 

■ Automatic delay following external event 
detection 



Each timer/counter is driven by its own 6-bit 
prescaler, which is in turn driven by the inter- 
nal Z8 clock divided by four. For Ti, the inter- 
nal clock may be gated or triggered by an 
external event or may be replaced by an exter- 
nal clock input. Each timer/counter may 
operate in either single-pass or continuous 
mode where, at end-of-count, either counting 
stops or the counter reloads and continues 
counting. The counter and prescaler registers 
may be altered individually while the timer/ 
counter is running; the software controls 
whether the new values are loaded immedi- 
ately or when end-of-count (EOC) is reached. 

Although the timer/counter prescaler 
registers (PREO and PRE1) are write-only, 
there is a technique by which the timer/ 
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7. Timer/ counters may simulate a readable prescaler. 

Counter This capability is a requirement for high 

Functions resolution measurement of an event's duration. 

(Continued) The basic approach requires that one timer/ 

counter be initialized with the desired counter 
and prescaler values. The second timer/ 
counter is initialized with a counter equal to 
the prescaler of the first timer/counter and a 
prescaler of 1 . The second timer/counter must 
be programmed for continuous mode. With 
both timer/counters driven by the internal 
clock and started and stopped simultaneously, 
they will run synchronous to one another; thus, 
the value read from the second counter will 
always be equivalent to the prescaler of 
the first. 

7.1 Time/Count Interval Calculation To 
determine the time interval (i) until EOC, the 
equation 

i = t x p x v 

characterizes the relation between the 
prescaler (p), counter (v), and clock input 
period (t); t is given by 

l/(XTAL/8) 

where XTAL is the Z8 input clock frequency; 
p is in the range 1 - 64; v is in the range 
1 -256. When programming the prescaler and 
counter registers, the maximum load value is 
truncated to six and eight bits, respectively, 
and is therefore programmed as zero. For an 
input clock frequency of 8 MHz, the prescaler 
and counter register values may be pro- 
grammed to time an interval in the range 

1 /lis x 1 x 1 < i < 1 (is x 64 x 256 

1 |is < i < 16.384 ms 

To determine the count (c) until EOC for T\ 
with external clock input, the equation 

c = p x v 

characterizes the relation between the Ti 
prescaler (p) and the Ti counter (v). The 
divide-by-8 on the input frequency is bypassed 
in this mode. The count range is 

1 x 1 < c < 64 x 256 

1 < c < 16,384 

7.2 Tqut Modes. Port 3, bit 6 (P36) may be 
configured as an output (Tout) which is 
dynamically controlled by one of the following: 

■ To 

■ Ti 

■ Internal clock 

When driven by Tq or Ti, Tout 1S reset to a 
logic 1 when the corresondmg load bit is set in 
timer control register TMR (%F1) and toggles 
on EOC from the corresponding counter. 



When Tout is driven by the internal clock, 
that clock is directly output on P3g. 

While programmed as Tout, P36 is disabled 
from being modified by a write to port register 
%03; however, its current output may be 
examined by the Z8 software by a read to port 
register %03. 

7.3 T IN Modes. Port 3, bit 1 (P3i) may be con- 
figured as an input (Tin) which is used in con- 
junction with Ti in one of four modes: 

■ External clock input 

■ Gate input for internal clock 

■ Nonretnggerrable input for internal clock 

■ Retnggerable input for internal clock 

For the latter two modes, it should be noted 
that the existence of a synchronizing circuit 
within the Z8 causes a delay of two to three 
internal clock periods following an external 
trigger before clocking of the counter actually 
begins. 

Each High-to-Low transition on Tjn will 
generate interrupt request IRQ2, regardless of 
the selected T/n mode or the enabled/disabled 
state of Tj. IRQ2 must therefore be masked or 
enabled according to the needs of the 
application. 

The "external clock input" Tin mode sup- 
ports the counting of external events, where an 
event is seen as a High-to-Low transition on 
Tin. Interrupt request IRQ5 is generated on 
the nth occurrence (single-pass mode) or on 
every nth occurrence (continuous mode) of 
that event. 

The "gate input for internal clock" Tin mode 
provides for duration measurement of an exter- 
nal event. In this mode, the Ti prescaler is 
driven by the Z8 internal clock, gated by a 
High level on Tin. I n other words, Ti will 
count while Tin is High and stop counting 
while Tin is Low. Interrupt request IRQ2 is 
generated on the High-to-Low transition on 
Tin. Interrupt request IRQ5 is generated on Ti 
EOC. This mode may be used when the width 
of a High-going pulse needs to be measured. 
In this mode, IRQ2 is typically the interrupt 
request of most importance, since it signals the 
end of the pulse being measured. If IRQ5 is 
generated prior to IRQ2 in this mode, the 
pulse width on Tin is too large for T\ to 
measure in a single pass. 

The "nonretriggerable input" Tin mode pro- 
vides for automatic delay timing following an 
external event. In this mode, Ti is loaded and 
clocked by the Z8 internal clock following the 
first High-to-Low transition on Tin after Ti is 
enabled. Tin transitions that occur after this 
point do not affect T\. In single-pass mode, the 
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7. Timer/ enable bit is reset on EOC; further Tin transi- 

Counter tions will not cause Tj to load and begin count- 

Functions ing until the software sets the enable bit again. 

(Continued) In continuous mode, EOC does not modify the 
enable bit, but the counter is reloaded and 
counting continues immediately; IRQ5 is 
generated every EOC until software resets the 
enable bit. This Tin mode may be used, for 
example, to time the line feed delay following 
end of line detection on a printer or to delay 
data sampling for some length of time follow- 
ing a sample strobe. 

The u retnggerable input" Tin mode will load 
and clock T\ with the Z8 internal clock on 
every occurrence of a High-to-Low transition 
on Tin- Ti will time-out and generate interrupt 
reguest IRQ5 when the programmed time 
interval (determined by T\ prescaler and load 
register values) has elapsed since the last 
High-to-Low transition on Tin. In single-pass 
mode, the enable bit is reset on EOC; further 
Tin transitions will not cause Ti to load and 
begin counting until the software sets the 
enable bit again. In continuous mode, EOC 
does not modify the enable bit, but the counter 
is reloaded and counting continues immedi- 



ately; IRQ5 is generated at every EOC until 
the software resets the enable bit. This Tjn 
mode may provide such functions as watch-dog 
timer (e.g., interrupt if conveyor belt stopped 
or clock pulse missed), or keyboard time-out 
(e.g., interrupt if no input in x ms). 

7.4 Examples. Several possible uses of the 
timer/counters are given in the following four 
examples. 

7 4.1 Time of Day Clock. The following 
module illustrates the use of Tj for 
maintenance of a time of day clock, which is 
kept in binary format in terms of hours, 
minutes, seconds, and hundredths of a second. 
It is desired that the clock be updated once 
every hundredth of a second; therefore, Tj is 
programmed in continuous mode to interrupt 
100 times a second. Although Ti is used for 
this example, Tq is egually suited for the task. 
The procedure for initializing the timer 

(TOD INIT), the interrupt service routine 

(TOD) which updates the clock, and the inter- 
rupt vector for Ti end-of-count (IRQ 5) are 

illustrated below. XTAL = 7.3728 MHz is 
assumed. 



Z8ASM 




2.0 












LOC 


OBJ 


CODE 


STMT SOURCE STATEMENT 












1 


TIMER1 MODULE 












2 


CONSTANT 














3 


HOUR 


= 


R12 










4 


MINUTE 


= 


R13 










5 


SECOND 


= 


R14 










6 


HUND 


= 


R15 










7 


$SECTI0N PROGRAM 










8 


GLOBAL 














9 


IIRQ5 int 


.errupt 


vector ! 










10 


j 


&ABS 


10 


P 0000 


000F» 




11 


IRQ_5 I 


IRRAY 


[1 WORD] := [TOD] 










12 
















13 


V 


&REL 




P oooc 








14 
15 


TOD INIT 
ENTRY 




PROCEDURE 


P 0000 


E6 


F3 


93 


16 
17 
18 
19 


I 


-D 


PRE1 ,#56(2)10010011 

!bit 2-7: prescaler = 36; 
bit 1: internal clock; 
bit 0: continuous mode! 


P 0003 


E6 


F2 


00 


20 
21 


I 


,D 


T1,#0 !(256) time-out = 
1/100 second! 


P 0006 


46 


F1 


OC 


22 


( 


3R 


TMR,#560C Iload, enable T1 ! 


P 0009 


8F 






23 


] 


)I 




P O00A 


46 


FB 


20 


24 


( 


DR 


IMR,#%20 !enable T1 interrupt! 


P O0OD 


9F 






25 


I 


:i 




P 000E 


AF 






26 




^ET 




P O0OF 








27 


END T0D_INIT 










28 








P 000F 








29 


TOD 


3 R0CEDURE 










30 


ENTRY 






P O0OF 


70 


FD 




31 




3 USH 


RP 










32 


IWorking 


regist 


sr file 5610 to 561F contains 










33 


the time 


2 of day clock! 


P 0011 


31 


10 




34 




3RP 


#5610 


P 0013 


FE 






35 




ENC 


HUND !1 more .01 sec! 


P 0014 


A6 


EF 


64 


36 


( 


;p 


HUND, #100 '.full second yet?! 


P 0017 


EB 


13 




37 


» 


JR 


NE,TOD_EXIT !jump if no! 


P 0019 


B0 


EF 




38 




:lr 


HUND 


P 001B 


EE 






39 




ENC 


SECOND !1 more second! 


P 001C 


A6 


EE 


3C 


40 




:p 


SECOND, #60 !full minute yet?! 


P 001F 


EB 


0B 




41 


* 


JR 


NE,T0D EXIT !jump if no! 
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Counter 

Functions 

(Continued) 



P 0021 BO 


EE 




42 




CLR 


SECOND 




P 0023 DE 






43 




INC 


MINUTE 


!1 more minute! 


P 0024 A6 


ED 


3C 


44 




CP 


MINUTE, #60 


Ifull hour yet?! 


P 0027 EB 


03 




45 




JR 


NE,TOD EXIT 


!jump if no! 


P 0029 BO 


ED 




46 




CLR 


MINUTE 




P 002B CE 






47 
48 


TOD_ 


INC 
EXIT: 


HOUR 




P 002C 50 


FD 




49 




POP 


RP 


!restore entry RP! 


P 002E BF 






50 




IRET 






P 002F 






51 
52 


END 
END 


TOD 
TIMER1 






ERRORS 














ASSEMBLY COMPLETE 












TOD_INIT: 










TOD: 






7 instructions 








17 instruction 




15 bytes 










32 bytes 




16 ps 










19.5 (is 


(average) including interrupt response time 



7.4.2 Variable Frequency, Variable Pulse 
Width Output. The following module 
illustrates one possible use of TquT- Assume it 
is necessary to generate a pulse train with a 
10% duty cycle, where the output is repetitive- 
ly high for 1.6 ms and then low for 14.4 ms. To 
do this, Tout 1S controlled by end-of-count 
from Ti, although To could alternately be 
chosen. This example makes use of the Z8 
feature that allows a timer's counter register to 
be modified without disturbing the count in 
progress. In continuous mode, the new value is 
loaded when T\ reaches EOC. Ti is first 
loaded and enabled with values to generate 
the short interval. The counter register is then 
immediately modified with the value to 
generate the long interval; this value is loaded 
into the counter automatically on Ti EOC. The 
prescaler selected value must be the same for 
both long and short intervals. Note that the 



initial loading of the T\ counter register is 
followed by setting the Ti load bit of timer con- 
trol register TMR (%F1); this action causes 
Tout to be reset to a logic 1 output. Each 
subsequent modification of the Ti counter 
register does not affect the current Tout level, 
since the Ti load bit is NOT altered by the 
software. The new value is loaded on EOC, 
and Tout will toggle at that time. The Ti inter- 
rupt service routine should simply modify the 
Ti counter register with the new value, alter- 
nating between the long and short interval 
values. 

In the example which follows, bit of 
register %04 is used as a software flag to indi- 
cate which value was loaded last. This module 
illustrates the procedure for Ti/ToUT initializa- 
tion (PULSE INIT), the Ti interrupt service 

routine (PULSE), and the interrupt vector for 
Ti EOC (IRQ__5). XTAL - 8 MHz is assumed. 



Z8ASM 
LOC 



2.0 
OBJ CODE 



STMT SOURCE STATEMENT 



P 0000 0017' 

P 000C 

P 0000 E6 F3 03 



P 0003 E6 
P 0006 E6 
P 0009 8F 
P 000A 46 
P 000D E6 



F7 
F2 

FB 
F1 



00 
19 

20 
8C 



P 0010 E6 F2 E1 



1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 

21 

22 

23 

24 

25 

26 



TIMER2 MODULE 

$SECTI0N PROGRAM 
GLOBAL 
!IRQ5 interrupt vector! 



IRQ_5 



$ABS 
ARRAY 



$REL 
PULSE_INIT 
ENTRY 

LD 



LD 
LD 
DI 
OR 
LD 



10 

[1 WORD] 



PROCEDURE 



[PULSE] 



PRE1, #55(2)00000011 

!bit 2-7: prescaler 



64; 



bit 1: internal clock; 

bit 0: continuous mode! 

P3M,#00 !bit 5: let P36 be Tout! 

T1,#25 !for short interval! 



IMR, #55(2)00100000 
TMR, #55(2)10001100 
Ibit 6-7: 



lenable T1 interrupt! 



Tout controlled 
by T1; 
bit 3: enable T1 ; 
bit 2: load T1 ! 
!Set long interval counter, to be loaded on T1 EOC! 

LD T1,#225 
!Clear alternating flag for PULSE! 
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Counter 
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(Continued) 



P 0013 


B0 


04 




27 
28 




CLR 


5504 


!= : 25 next; 
= 1 : 225 next ! 


P 0015 


9F 






29 




EI 






P 0016 


AF 






30 




RET 






P 0017 








31 


END 


PULSE_INIT 












32 


















33 










P 0017 








34 


PULSE 


PROCEDURE 












35 


ENTRY 








P 0017 


E6 


F2 


E1 


36 




LD 


T1 ,#225 


!new load value! 


P 001A 


B6 


04 


01 


37 




X0R 


5504, #1 


!which value next?! 


P 001D 


6B 


03 




38 




JR 


Z, PULSE EXIT 


!should be 225! 


P 001F 


E6 


F2 


19 


39 
40 


PULSE. 


LD 
EXIT: 


T1,#25 


!should be 25! 


P 0022 


BF 






41 




IRET 






P 0023 








42 
43 


END 
END 


PULSE 
TIMER2 






ERRORS 














ASSEMBLY COMPLETE 












PULSE_ 


INIT: 










PULSE: 






10 instructions 








5 instructions 




23 bytes 










12 bytes 






23 lis 












25 fts (average) including interrupt response time 



7.4.3 Cascaded Timer/Counters. For some 
applications it may be necessary to measure a 
greater time interval than a single timer/ 
counter can measure (16.384 ms). In this case, 
Tin and Tout may be used to cascade To and 






-*- TO INTERRUPT LOGIC (IRQ4) 



T] to function as a single unit. Tout, program- 
med to toggle on To end-of-count, should be 
wired back to Tin, which is selected as the 
external clock input for Tj . With To program- 
med for continuous mode, Tout (and therefore 
Tin) goes through a High-to-Low transition 
(causing T\ to count) on every other To EOC. 
Interrupt request IRQ5 is generated when the 
programmed time interval has elapsed. Inter- 
rupt requests IRQ2 (generated on every Tjn 
High-to-Low transition) and IRQ4 (generated 
on To EOC) are of no importance in this 
application and are therefore disabled. 

To determine the time interval (l) until EOC, 
the equation 

i = t x pO x vO x (2 x pi x vl-1) 

characterizes the relation between the To 
prescaler (pO) and counter (v0) ; the Ti 
prescaler (pi) and counter (vl), and the clock 
input period (t); t is defined in Section 7.1. 
Assuming XTAL = 8 MHz, the measurable 
time interval range is 



1/ts x 1 x 1 x(2x 1 - 1) < i < 
1 /is x 64 x 256 x (2 x 64 x 256 

1 fis < i < 536.854528 s 



1) 



-► TO INTERRUPT LOGIC (IRQ5) 



Figure 3 illustrates the interconnection 
between Tq and T\. The following module 
illustrates the procedure required to initialize 
the timers for a 1.998 second delay interval: 



Figure 3. Cascaded Timer/Counters 
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7. Timer/ 


Z8ASM 




2.0 












Counter 


LOC 


OBJ 


CODE 


STMT SOURCE 


STATEMENT 




Functions 










1 


TIMER3 


MODULE 




(Continued) 










2 


GLOBAL 








P 0000 








3 

4 


TIMER 
ENTRY 


16 


PROCEDURE 




P 0000 


E6 


F3 


28 


5 
6 
7 
8 




LD 


PRE1 ,#$(2)00101000 

!bit 2-7: prescaler = 10; 
bit 1: external clock; 
bit 0: single-pass mode! 




P 0003 


E6 


F7 


00 


9 




LD 


P3M,#00 !bit 5: let P36 be Tout! 




P 0006 


E6 


F2 


64 


10 




LD 


T1,#100 !T1 counter register! 




P 0009 


E6 


F5 


29 


11 
12 
13 




LD 


PREO, #$(2)00101001 

!bit 2-7: prescaler = 10; 
bit 0: continuous mode! 




P OOOC 


E6 


F4 


64 


14 




LD 


TO, #100 !T0 counter register! 




P 000F 


8F 






15 




DI 






P 0010 


56 


FB 


2B 


16 
17 




AND 


IMR, #$(2)00101011 !disable IRQ2 (Tin); 
and IRQ4 (TO) ! 




P 0013 


46 


FB 


20 


18 




OR 


IMR, #$(2)00100000 !enable IRQ5 (T1)! 




P 0016 


9F 






19 




EI 






P 0017 


E6 


F1 


4F 


20 
21 
22 
23 
24 
25 
26 
27 
28 




LD 


TMR,#$(2)01001111 

!bit 6-7: Tout controlled 
by TO; 
bit 4-5: Tin mode is ext. 

clock input; 
bit 3: enable T1 ; 
bit 2: load T1 ; 
bit 1 : enable TO; 
bit 0: load TO ! 




P 001A 


AF 






29 




RET 






P 001B 








30 


END 


TIMER 16 












31 


END 


TIMER3 






ERRORS 














ASSEMBLY COMPLETE 












11 instructions 














27 bytes 


















26.5 fis 

















7.4.4 Clock Monitor. Tj and Tin m ^y be used 
to monitor a clock line (in a diskette drive, for 
example) and generate an interrupt request 
when a clock pulse is missed. To accomplish 
this, the clock line to be monitored is wired to 
P3i (Tin)- Tjn should be programmed as a 
retnggerable input to T\, such that each fall- 
ing edge on Tin will cause T\ to reload and 
continue counting. If Tj is programmed to 
time-out after an interval of one-and-a-half 
times the clock period being monitored, T\ 
will time-out and generate interrupt request 
IRQ5 only if a clock pulse is missed. 



The following module illustrates the pro- 
cedure for initializing Tj and Tin 
(MONITOR_INIT) to monitor a clock with a 
period of 2 /xs. XTAL = 8 MHz is assumed. 
Note that this example selects single-pass 
rather than continuous mode for Ti. This is to 
prevent a continuous stream of IRQ5 interrupt 
requests m the event that the monitored clock 
fails completely. Rather, the interrupt service 

routine (CLK ERR) is left with the choice of 

whether or not to re-enable the monitoring. 
Also shown is the Ti interrupt vector (IRQ 5). 



Z8ASM 
LOC 



2.0 
OBJ CODE 



STMT SOURCE STATEMENT 



1 TIMER4 MODULE 

2 $SECTI0N PROGRAM 

3 GLOBAL 

4 !IRQ5 interrupt vector! 













5 




$ABS 


10 


p 


0000 


0015' 




6 

7 
8 


IRQ_5 


ARRAY 


[1 WORD] := [CLK_ERR] 














$REL 




p 


OOOC 








9 
10 


MONITOR 
ENTRY 


_INIT 


PROCEDURE 


p 


0000 


E6 


F3 


04 


11 
12 
13 
14 




LD 


PRE1 ,#$(2)00000100 

!bit 2-7: prescaler = 1; 
bit 1: external clock; 
bit 0: single-pass mode! 


p 


0003 


E6 


F7 


00 


15 




LD 


P3M,#00 !bit 5: let P36 be Tout! 


p 


0006 


E6 


F2 


03 


16 
17 




LD 


T1,#3 !T1 load register, 
=1.5*2 usee ! 
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P 


0009 


8F 






18 






DI 


Counter 


P 


OO0A 


56 


FB 


3B 


19 






AND IMR,«(2)00111011 Idisable IRQ2 (Tin)! 


Functions 


P 
P 


000D 
0010 


46 
9F 


FB 


20 


20 
21 






OR IMR, #56(2)00100000 lenable IRQ5 (T1)! 
EI 


(Continued) 












22 










P 


0011 


E6 


F1 


38 


23 
24 
25 
26 






LD TMR, #56(2)00111000 

Ibit 4-5: Tin mode is 

retrig. input; 
bit 3: enable T1 ! 




P 


0014 


AF 






21 






RET 




P 


0015 








28 
29 
30 


END 




MONITOR_INIT 




P 


0015 








31 


CLK 


.ERR 


PROCEDURE 














32 


ENTRY 
















33 






!...! Jhandle the missed clock! 














34 




















35 


!if 


clock monitoring should continue...! 




P 


0015 


46 


F1 


08 


36 
37 






OR TMR, #56(2)00001000 

ibit 3: enable T1 ! 




P 


0018 


BF 






38 






IRET 




P 


0019 








39 
40 


END 
END 




CLK ERR 
TIMER4 






ERRORS 














ASSEMBLY COMPLETE 












MONITOR^INIT: 










CLK_ERR: 






9 instructions 










2 + instructions 






21 byte 


s 












4 + bytes 






21.5 us 














18.5 + /is including interrupt response time 



SECTION 

8 



I/O Functions 

The Z8 provides 32 I/O lines mapped into 
registers 0-3 of the internal register file. Each 
nibble of port is individually programmable 
as input, output, or address/data lines 
(A15-A12, Ail-As). Port 1 is programmable as 
a single entity to provide input, output, or 
address/data lines (AD7-AD0). The operating 
modes for the bits of Ports and 1 are selected 
by control register P01M (%F8). Selection of 
I/O lines as address/data lines supports access 
to external program and data memory; this is 
discussed in Section 3. Each bit of Port 2 is 
individually programmable as an input or an 



Function 


Bit 


Signal 




f P3i 


DAV2/RDY2 




P3 2 


DAV0/RDY0 


Handshake 


P3 3 

P3 4 


DAV1/RDY1 
RDY1/DAV1 




P3 5 


RDY0/DAV0 




P3 6 


RDY2/DAV2 





fP3 


IRQ3 


Interrupt 


P3i 


IRQ2 


Request 


P3 2 


IRQ0 




lP3 3 


IRQ1 


Counter/ 


|P3l 


T IN 


Timer 


1P3 6 


T OUT 


Data Memory 
Select 


P3 4 


DM 


Status Out 
Serial I/O 


l 

fP3 
JP3 7 


Serial In 
Serial Out 



Table 4. Port 3 Special Functions 



output bit. Port 2 bits programmed as outputs 
may also be programmed (via bit of P3M) to 
all have active pull-ups or all be open-dram 
(active pull-ups inhibited). In Port 3, four bits 
(P3o~P33) are fixed as inputs, and four bits 
(P34-P37) are fixed as outputs, but their func- 
tions are programmable. Special functions pro- 
vided by Port 3 bits are listed in Table 4. Use 
of the Data Memory select output is discussed 
in Section 3; uses of Tin and Tout are dis- 
cussed in Section 7. 

8.1 Asynchronous Receiver/ Transmitter 
Operation. Full-duplex, serial asynchronous 
receiver/transmitter operation is provided by 
the Z8 via P37 (output) and P3n (input) in con- 
junction with control register SIO (%F0), 
which is actually two registers: receiver buffer 
and transmitter buffer. Counter/Timer Tq pro- 
vides the clock for control of the bit rate. 

The Z8 always receives and transmits eight 
bits between start and stop bits. However, if 
parity is enabled, the eighth bit (D7) is 
replaced by the odd-parity bit when trans- 
mitted and a parity-error flag ( = 1 if error) 
when received. Table 5 illustrates the state of 
the parity bit/parity error flag during serial 
I/O with parity enabled. 

Although the Z8 directly supports either odd 
parity or no parity for serial I/O operation, 
even parity may also be provided with addi- 
tional software support. To receive and 
transmit with even parity, the Z8 should be 
configured for serial I/O with odd parity 
disabled. The Z8 software must calculate parity 
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Character Loaded 


Transmitted To 


Received From 


Character 




Functions 


Into SIO 


Serial Line 


Serial Line 


Transferred To SIO 


Note* 


(Continued) 


11000011 


01000011 


01000011 


01000011 


no error 




11000011 


01000011 


01000111 


11000111 


error 




01111000 


11111000 


11111000 


01111000 


no error 




01111000 


11111000 


01111000 


11111000 


error 



Table 5. Serial I/O With Odd Parity 



* Left-most bit is D7 



and modify the eighth bit prior to the load of a 
character into SIO and then modify a parity 
error flag following the load of a character 
from SIO. All other processing reguired for 
serial I/O (e.g. buffer management, error 
handling, etc.) is the same as that for odd 
parity operations. 

To configure the Z8 for Serial I/O, it is 
necessary to: 

■ Enable P3o and P37 for serial I/O and select 
parity, 

■ Set up To for the desired bit rate, 

■ Configure IRQ3 and IRQ4 for polled or 
automatic interrupt mode, 

■ Load and enable To. 

To enable P3q and P37 for serial I/O, bit 6 of 
P3M (R247) is set. To enable odd parity, bit 7 
of P3M is set; to disable it, the bit is reset. For 
example, the instruction 

LD P3M,#%40 

will enable serial I/O, but disable parity. The 
instruction 

LD P3M,#%C0 

will enable serial I/O, and enable odd parity. 

In the following discussions, bit rate refers to 
all transmitted bits, including start, stop, and 
parity (if enabled). The serial bit rate is given 
by the equation: 

input clock frequency 



(2 x 4 x Tq prescaler x To counter x 16) 

The final divide-by- 16 is incurred for serial 
communications, since in this mode Tq runs at 
16 times the bit rate in order to synchronize 
the data stream. To configure the Z8 for a 
specific bit rate, appropriate values must first 
be selected for To prescaler and Tq counter by 
the above equation; these values are then pro- 
grammed into registers Tq (%F4) and PRE0 
(%F5) respectively. Note that PRE0 also con- 
trols the continuous vs. single-pass mode for 
To; continuous mode should be selected for 
serial I/O. For example, given an input clock 
frequency of 7.3728 MHz and a selected bit 
rate of 9600 bits per second, the equation is 



satisfied by Tq counter = 2 and prescaler = 3. 
The following code sequence will configure the 
Tq counter and To prescaler registers: 

LD T 0# #2 ! T counter = 2! 
LD PRE0,#%(2)00001101 

!bit 2-7: prescaler = 3; bit 0: 

continuous mode! 

Interrupt request 3 (IRQ3) is generated 
whenever a character is transferred into the 
receive buffer; interrupt request 4 (IRQ4) is 
generated whenever a character is transferred 
out of the transmit buffer. Before accepting 
such interrupt requests, the Interrupt Mask, 
Request, and Priority Registers (IMR, IRQ, and 
IPR) must be programmed to configure the 
mode of interrupt response. The section on 
Interrupt Processing provides a discussion of 
interrupt configurations. 

To load and enable Tq, set bits and 1 of 
the timer mode register (TMR) via an instruc- 
tion such as 

OR TMR,#%03 

This will cause the Tq prescaler and counter 
registers (PRE0 and To) to be transferred to the 
To prescaler and counter. In addition, To is 
enabled to count, and serial I/O operations 
will commence. 

Characters to be output to the serial line 
should be written to serial I/O register SIO 
(%F0). IRQ4 will be generated when all bits 
have been transferred out. 

Characters input from the serial line may be 
read from SIO. IRQ3 will be generated when a 
full character has been transferred into SIO. 

The following module illustrates the receipt 
of a character and its immediate echo back to 
the serial line. It is assumed that the Z8 has 
been configured for serial I/O as described 
above, with IRQ3 (receive) enabled to interrupt, 
and IRQ4 (transmit) configured to be polled. 
The received character is stored in a circular 
buffer in register memory from address %42 to 
%5F. Register %41 contains the address of 
the next available buffer position and should 
have been initialized by some earlier routine 
to #%42. 
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8. I/O 


Z8ASM 




2.0 












Functions 


LOC 


OBJ 


CODE 


STMT SOURCE 


STATEMENT 




(Continued) 












1 


SERIAL 


_io 


MODULE 














2 


CONSTANT 
















3 


next_ 


.addr 


:= 7*41 














4 


start 




:= %H2 














5 


length 


: = % 1 E 














6 


$SECTION PROGRAM 














7 


GLOBAL 


















8 


!IRQ3 


vector ! 
















9 




$ABS 


6 




P 


0006 


0000' 




10 
11 
12 


IRQ_3 


ARRAY [1 WORD] := [GET_CHARACTER] 
















$REL 







P 


0000 








13 


GET_CHARACTER 


PROCEDURE ENTRY 














14 




















15 


ISeric 


1 I/O receive interrupt service! 














16 


!Echo 


received 


character and wait for 














17 


echo 


completio 


n! 




P 


0000 


E4 


FO 


FO 


18 
19 




Id 


SIO,SIO !echo! 














20 


.'save 


it in circular buffer! 




P 


0003 


F5 


FO 


41 


21 




Id 


@next_addr , SIO !save in buffer! 




P 


0006 


20 


41 




22 




inc 


next_addr !point to next position! 




P 


0008 


A6 


41 


60 


23 
24 




cp 


next_addr , #start+ length 

!wrap-around yet?! 




P 


000B 


EB 


03 




25 




jr 


ne, echo_wait !no. ! 




P 


000D 


E6 


41 


42 


26 
27 


!now, 


Id 
wait for 


next_addr, //start !yes. point to start! 
echo complete! 














28 


echo_wait : 






P 


0010 


66 


FA 


10 


29 




tcm 


IRQ, #5610 transmitted yet?! 




P 


0013 


EB 


FB 




30 
31 




jr 


nz,echo_wait !not yet! 




P 


0015 


56 


FA 


EF 


32 




and 


IRQ,#%EF !clear IRQ4 ! 




P 


0018 


BF 






33 




IRET 


•.return from interrupt! 




P 


0019 








34 


END 


GET CHARACTER 














35 


END 


SERIAL 


10 






ERRORS 














ASSEMBLY COMPLETE 











10 instructions 
25 bytes 

35.5 (is + 5.5 (is for each additional pass through the echo wait loop, 

including interrupt response time 



8.2 Automatic Bit Rate Detection. In a typical 
system, where serial communication is 
required (e.g. system with a terminal), the 
desired bit rate is either user-selectable via a 
switch bank or nonvanable and "hard-coded" 
in the software. As an alternate method of bit- 
rate detection, it is possible to automatically 
determine the bit rate of serial data received 
by measuring the length of a start bit. The 
advantage of this method is that it places no 
requirements on the hardware design for this 
function and provides a convenient (automatic) 
operator interface. 

In the technique described here, the serial 
channel of the Z8 is initialized to expect a bit 
rate of 19,200 bits per second. The number of 
bits (n) received through Port pin P30 for each 
bit transmitted is expressed by 

n = 19,200/b 

where b = transmission bit rate. For example, 
if the transmission bit rate were 1200 bits per 
second, each incoming bit would appear to the 
receiving serial line as 19,200/1200 or 16 bits. 
The following example is capable of disting- 



uishing between the bit rates shown in Table 6 
and assumes an input clock frequency of 
7.3728 MHz, a Tq prescaler of 3, and serial I/O 
enabled with parity disabled. This example 
requires that a character with its low order 
bit = 1 (such as a carnage return) be sent to 
the serial channel. The start bit of this 
character can be measured by counting the 
number of zero bits collected before the low 
order 1 bit. The number of zero bits actually 
collected into data bits by the serial channel is 
less than n (as given in the above equation), 
due to the detection of start and stop bits. 
Figure 4 illustrates the collection (at 19,200 



ST { m [ PI j P2 | m | M { OS | D6 | P7 1 SP i ST | 06 \ Ot j Q2 j 03 j P4 
|** 1 BIT TIME AT 1,200 BITS PER SECOND fr»| 



ST = START BIT SP = STOP BIT Dn = DATA BIT n 



Figure 4. Collection of a Start Bit Transmitted at 
1,200 BPS and Received at 19,200 BPS 
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8. I/O 




Number of Bits Received 


Number of Bits Collected 






Functions 


Bit Rate 


Per Bit Transmitted 


as 


Data Bits 


To 


Counter 


(Continued) 






dec 


binary 


dec 


binary 




19200 


1 





00000000 


1 


00000001 




9600 


2 


1 


00000001 


2 


00000010 




4800 


4 


3 


00000011 


4 


00000100 




2400 


8 


7 


00000111 


8 


00001000 




1200 


16 


13 


00001101 


16 


00010000 




600 


32 


25 


00011001 


32 


00100000 




300 


64 


49 


00110001 


64 


01000000 




150 


128 


97 


01100001 


128 


10000000 



Table 6. Inputs to the Automatic Bit Rate Detection Algorithm 



bits per second) of a zero bit transmitted to the 
Z8 at 1,200 bits per second. Notice that only 13 
of the 16 zero bits received are collected as 
data bits. 

Once the number of zero bits in the start bit 
has been collected and counted, it remains to 
translate this count into the appropriate Tq 
counter value and program that value into Tq 
(%F4). The patterns shown in the two binary- 
columns of Table 6 are utilized in the 
algorithm for this translation. 

As a final step, if incoming data is to com- 
mence immediately, it is advisable to wait until 
the remainder of the current "elongated" 



character has been received, thus "flushing" 
the serial line. This can be accomplished 
either via a software loop, or by programming 
T\ to generate an interrupt reguest after 
the appropriate amount of time has elapsed. 
Since a character is composed of eight bits 
plus a minimum of one stop bit following the 
start bit, the length of time to delay may be 
expressed as 

(9 x n)/b 

where n and b are as defined above. The 
following module illustrates a sample program 
for automatic bit rate detection. 



Z8ASM 




2.0 














L0C 


OBJ 


CODE 


STMT SOURCE STATEMENT 












1 


bit rate 


MODULE 












2 


EXTERNAL 














3 


DELAY 


PROCEDURE 












4 


GLOBAL 








P 0000 








5 


main 


PROCEDURE 












6 




ENTRY 






P 0000 


8F 






7 




di 




(disable interrupts! 


P 0001 


56 


FB 


77 


8 




and 


IMR,#%77 


!IRQ3 polled mode! 


P 0004 


56 


FA 


F7 


9 




and 


IRQ,#%F7 


.'clear IRQ3! 


P 0007 


E6 


F7 


40 


10 




Id 


P3M,#%40 


!enable serial I/O! 


P 0C0A 


E6 


F4 


01 


11 




Id 


T0,#1 




P 000D 


E6 


F5 


0D 


12 




Id 


PRE0,#(3 SHL 2)+1 !bit rate = 19,200; 










13 








continuous count mode! 


P 0010 


B0 


E0 




14 




clr 


R0 


Unit, zero byte counter! 


P 0012 


E6 


F1 


03 


15 
16 
17 




Id 


TMR,#3 


!load and enable TO! 










Icolled 


b input 


bytes by counting the number of null 










18 


charac 


ters received. Stop 


when non-zero byte received! 










19 


collect 








P 0015 


76 


FA 


08 


20 




TM 


IRQ,#%08 


!character received?! 


P 0018 


6B 


FB 




21 




jr 


z, collect 


!not yet! 


P 001A 


18 


F0 




22 




Id 


R1 ,SIO 


!get the character! 


P 001C 


56 


FA 


F7 


23 




and 


IRQ,#%F7 


!clear interrupt request! 


P 001F 


1E 






24 




inc 


R1 


!compare to . . . ! 


P 0020 


1A 


05 




25 




djnz 


R1 , bitloop 


!...(in 3 bytes of code)! 


P 0022 


06 


E0 


08 


26 




add 


R0,#8 


!update count of bits! 


P 0025 


8B 


EE 




27 
28 
29 


bitloop 


jr 


collect 


!add in zero bits from low 
end of 1st non-zero byte! 


P 0027 


E0 


E1 




30 




RR 


R1 




P 0029 


7B 


03 




31 




jr 


c, count done 


P 002B 


0E 






32 




inc 


R0 




P 002C 


8B 


F9 




33 
34 




jr 


bitloop 












35 


!R0 has 


number 


of zero bits 


collected ! 










36 


! transl 


ate R0 1 


to the appropriate TO counter value! 










37 


count_done: 




! R0 has count of zero bits! 


P 002E 


1C 


07 




38 




Id 


R1,#7 




P 0030 


2C 


80 




39 




Id 


R2,«80 


! R2 will have TO counter value ! 


P 0032 


90 


E0 




40 
41 
42 




RL 


R0 




P 0034 


90 


E0 




loop: 


RL 


R0 
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8. I/O 
Functions 

(Continued) 


P 
P 
P 


0036 7B 
0038 EO 
003A 1A 


04 
E2 
F8 




P 


003C 29 


F4 




P 


003E D6 


0000* 




P 


0041 56 


FA F7 




P 


0044 






ERRORS 
ASSEMBLY COMPLETE 



43 jr c,done 

44 RR R2 

45 djnz r1 ,loop 
46 

47 done: Id TO , R2 'load value for detected 

48 bit rate! 

49 IDelay long enough to clear serial line of bit stream! 

50 call DELAY 

51 !clear receive interrupt request! 

52 and IRQ,«F7 
53 

54 END main 

55 END bit_rate 



30 instructions 

68 bytes 

Execution time is variable based on transmission bit rate. 



8.3 Port Handshake. Each of Ports 0, 1 and 2 
may be programmed to function under input or 
output handshake control. Table 7 defines the 
port bits used for the handshaking and the 
mode bit settings required to select handshak- 
ing. To input data under handshake control, 
the Z 8 should read the input port when the 
DAV input goes Low (signifying that data is 
available from the attached device) . To output 
data under handshake control, the Z8 should 
write the output port when the RDY input goes 
Low (signifying that the previously output data 
has been accepted by the attached device). 
Interrupt requests IRQ0, IRQ1, and IRQ2 are 
generated by the falling edge of the handshake 
signal input to the Z8 for Port 0, Port 1, and 
Port 2 respectively. Port handshake operations 
may therefore be processed under interrupt 
control. 

Consider a system that requires communica- 
tion of eight parallel bits of data under hand- 
shake control from the Z8 to a peripheral 
device and that Port 2 is selected as the output 
port. The following assembly code illustrates 
the proper sequence for initializing Port 2 for 
output handshake. 



CLR P2M IPort 2 mode register: all Port 
2 bits are outputs! 

OR %03,#%40 

!set DAV2: data not available! 
LD P3M,#%20 

!Port 3 mode register: enable 
Port 2 handshake! 

LD %02,DATA 

! output first data byte; DAV2 
will be cleared by the Z8 to 
indicate data available to 
the peripheral device! 
Note that following the initialization of the out- 
put sequence, the software outputs the first 
data byte without regard to the state of the 
RDY2 input; the Z8 will automatically hold 
DAV2 High until the RDY2 input is High. The 
peripheral device should force the Z8 RDY2 
input line Low after it has latched the data in 
response to a Low on DAV2. The Low on RDY2 
will cause the Z8 to automatically force DAV2 
High until the next byte is output. Subsequent 
bytes should be output in response to interrupt 
request IRQ2 (caused by the High-to-Low tran- 
sition on RDY2) in either a polled or an 
enabled interrupt mode. 



PortO 



Port 1 



Port 2 



Input handshake lines 
Output handshake lines 



/ P3 2 = DAV 
\P3 5 = RDY 

/P3 2 = RDY 
}P3 5 = DAV 



DAV 
RDY 



P3 3 
P3 4 

P3 3 = RDY 
P3 4 = DAV 



DAV 
RDY 



P3i 
P3 6 

P3i = RDY 
P3 6 



: DAV 



To select input handshake: 



To select output handshake: 



To enable handshake. 



{set bit 6 & reset bit 7 of 
P01M (program high 
nibble as input) 

[reset bits 6, 7 of P01M 
\ (program high nibble as 
( output) 

set bit 5 of Port 3 (P3 5 ); 
set bit 2 of P3M 



set bit 3 & reset bit 4 of 
P01M (program byte as 
input) 

reset bits 3, 4 of P01M 
(program byte as output) 



set bit 4 of Port 3 (P3 4 ), 
set bits 3, 4 of P3M 



set bit 7 of P2M 

(program high bit as input) 

reset bit 7 of P2M 
(program high bit as output) 

set bit 6 of Port 3 (P3 6 ); 
set bit 5 of P3M 



Table 7. Port Handshake Selection 
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SECTION 

9 



Arithmetic Routines 

This section gives examples of the arithmetic 
and rotate instructions for use in multiplica- 
tion, division, conversion, and BCD arithmetic 
algorithms. 

9.1 Binary to Hex ASCII. The following 
module illustrates the use of the ADD and 
SWAP arithmetic instructions in the conversion 
of a 16-bit binary number to its hexadecimal 
ASCII representation. The 16-bit number is 
viewed as a string of four nibbles and is pro- 



cessed one nibble at a time from left to right, 
beginning with the high-order nibble of the 
lower memory address. %30 is added to each 
nibble if it is in the range to 9; otherwise 
%37 is added. In this way, %0 is converted to 
%30, %1 to %31, . . . %A to %41, . . . %F to 
%46. Figure 5 illustrates the conversion of RRO 
(contents = %F2BE) to its hex ASCII 
equivalent; the destination buffer is pointed to 
by RR4. 



1 c 



Figure 5. Conversion of (RRO) to Hex ASCII 



Z8ASM 2.99 
LOC OBJ CODE 



P 0000 



0009 06 
000C A6 
000F 7B 
0011 06 
0014 92 
0016 A0 



E2 
E2 
03 
E2 
24 
E4 



P 0018 A6 E6 

P 001B EB 02 

P 001D 08 E1 

P 001F 6A E1 
P 0021 AF 
P 0022 



INTERNAL RELEASE 
STMT SOURCE STATEMENT 

1 ARITH MODULE 

2 GLOBAL 

3 BINASC PROCEDURE 



P 0000 6C 04 

P 0002 F0 E0 

P 0004 28 E0 

P 0006 56 E2 OF 



30 
3A 



07 



03 






Purpose = 



4 

5 

6 

7 

8 Input = 

9 
10 
11 
12 
13 
14 
15 



To convert a 16-bit binary 
number to Hex ASCII 

RRO = 16-bit binary number. 
RR4 = pointer to destination 

buffer in external memory. 



Output = 



Resulting ASCII string (4 bytes) 
in destination buffer. 
RR4 incremented by 4 . 
15 R0,R2,R6 destroyed. 

15 a****************************************************; 

17 ENTRY 



U 

19 

20 again: 

21 

22 



Id 

SWAP 
Id 
and 



23 Iconvert to ASCII 



24 

25 ! 

26 

27 

28 

29 

30 skip: 

31 

32 

33 

34 

35 



R6,//%04 Inibble count! 

R0 '.look at next nibble! 

R2,R0 

R2,//7*0F !isolate 4 bits! 

R2 + #56 30 if R0 in range to 9 
else R2 + # % 3 7 (in range 0A to OF) 



ADD 

cp 

jr 

ADD 

lde 

incw 

cp 
jr 
Id 



R2,#7*30 
R2,«3A 
ult, skip 
R2,#%07 
@RR4 ,R2 
RR4 



!save ASCII in buffer! 
'.point to next 
buffer position! 
R6,«03 '.time for second byte?! 



36 same_byte: 

37 djnz 

38 ret 

39 END BINASC 

40 END ARITH 



ne , same_by te 
R0,R1 

R6, again 



'.no. ! 

!2nd byte! 



errors 
Assembly complete 



15 instructions 

34 bytes 

120.5 us (average) 
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9. Arithmetic 9.2 BCD Addition. The following module lllus- 
Routines trates the use of the add with carry (ADC) and 

(Continued) decimal adjust (DA) instructions for the addi- 
tion of two unsigned BCD strings of egual 
length. Within a BCD string, each nibble 
represents a decimal digit (0-9). Two such 
digits are packed per byte with the most 



significant digit in bits 7-4. Bytes within a 
BCD string are arranged in memory with the 
most significant digits stored in the lowest 
memory location. Figure 6 illustrates the 
representation of 5970 in a 6-digit BCD string, 
starting in register %33. 



Do D 7 

ID C 



Do D 7 

3 C 



Figure 6. Unsigned BCD Representation 



Z8ASM 




2.0 








LOC 


OBJ 


CODE 


STMT SOURCE STATEMENT 










1 


ARITH MODULE 










2 


CONSTANT 










3 


BCD SRC := R1 










4 


BCD_DST := R0 










5 


BCD LEN := R2 










6 


GLOBAL 




P 0000 






7 
8 


BCDADD PROCEDURE 
t*#*****«**x******tt*x#***********x*****xx****x******** 








9 


Purpose = 


To add two packed BCD strings of 








10 




equal length. 








11 




dst < — dst + src 








12 












13 


Input = 


R0 = pointer to dst BCD string. 








14 




R1 = pointer to src BCD string. 








15 




R2 = byte count in BCD string 








16 




(digit count = (R2)*2 ). 








17 












18 


Output = 


BCD string pointed to by R0 is 








19 




the sum. 








20 




Carry FLAG = 1 if overflow. 








21 




R0 , R1 as on entry. 








22 




R2 = 








23 


XXXXXXXX*XXXXX*XXXXXXXXXXXXXXXXXXXXXXX*XXXXXXXXXXXXXXf 








24 


ENTRY 










25 






P 0000 


02 


12 


26 


add 


BCD_SRC,BCD_LEN .'start at least... ! 


P 0002 


02 


02 


27 


add 


BCD_DST,BCD_LEN {significant digits! 


P 0004 


CF 




28 
29 


rcf 
add_again : 


Icarry = 0! 


P 0005 


00 


E1 


30 
31 


dec 


BCD_SRC !point to next two 
src digits! 


P 0007 


00 


E0 


32 
33 


dec 


BCD_DST Spoint to next two 
dst digits! 


P 0009 


E3 


31 


34 


Id 


R3,@BCD_SRC !get src digits! 


P 000B 


13 


30 


35 


ADC 


R3,@BCD_DST !add dst digits! 


P 000D 


40 


E3 


36 


DA 


R3 .'decimal adjust! 


P 000F 


F3 


03 


37 


Id 


@BCD_DST,R3 !move to dst! 


P 0011 


2A 


F2 


38 
39 


djnz 


BCD_LEN,add_again !loop for next 
digits! 


P 0013 


AF 




40 
41 


ret 


fall done! 


P 0014 






42 
43 


END BCDADD 
END ARITH 




ERRORS 








ASSEMBLY COMPLETE 









11 instructions 
20 bytes 

Execution time is a function of the number of bytes (n) m input BCD string: 
20 its + 12.5 (n - 1) its 



2009-1108 
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9. Arithmetic 9.3 Multiply. The following module illustrates 
Routines an efficient algorithm for the multiplication of 

(Continued) two unsigned 8-bit values, resulting in a 16-bit 
product. The algorithm repetitively shifts the 
multiplicand right (using RRC), with the low- 
order bit being shifted out (into the carry flag). 
If a one is shifted out, the multiplier is added 



to the high-order byte of the partial product. 
As the high-order bits of the multiplicand are 
vacated by the shift, the resulting partial- 
product bits are rotated in. Thus, the multipli- 
cand and the low byte of the product occupy 
the same byte, which saves register space, 
code, and execution time. 



Z8ASM 




2.99 


INTERNAL RELEASE 


LOC 


OBJ 


CODE 


STMT 

1 
2 


SOURCE STATEMENT 

ARITH MODULE 
CONSTANT 








3 


MULTIPLIER 


R1 








4 


PR0DUCT_L0 


R3 








5 


PRODUCT HI 


R2 








6 


COUNT 


R0 








7 


GLOBAL 


P 0000 






8 
9 
10 
11 
12 
13 


MULT PROCEDURE 

1 a**************************************************** 

Purpose = To perform an 8-bit by 8-bit unsigned 
binary multiplication. 








Input = R1 = multiplier 








14 


R3 = multiplicand 








15 










16 


Output = RR2 = product 








17 


R0 destroyed 








18 


********#************************#*******************! 








19 


ENTRY 


P 0000 


OC 


09 


20 


Id COUNT, #9 !8 BITS + 1 ! 


P 0002 


B0 


E2 


21 


clr PRODUCT_HI UNIT HIGH RESULT BYTE! 


P 0004 


CF 




22 


RCF .'CARRY = 0! 


P 0005 


CO 


E2 


23 


LOOP: RRC PRODUCT HI 


P 0007 


CO 


E3 


24 


RRC PR0DUCT_L0 


P 0009 


FB 


02 


25 


jr NC,NEXT 


P 000B 


02 


21 


26 


ADD PRODUCT HI, MULTIPLIER 


P 000D 


0A 


F6 


27 


NEXT: djnz COUNT, LOOP 


P 000F 


AF 




28 


ret 


P 0010 






29 
30 


END MULT 
END ARITH 


errors 






Assembly complete 






9 instructions 








16 bytes 










92.5 fjus (average) 







9.4 Divide. The following module illustrates 
an efficient algorithm for the division of a 
16-bit unsigned value by an 8-bit unsigned 
value, resulting in an 8-bit unsigned guotient. 
The algorithm repetitively shifts the dividend 
left (via RLC). If the high-order bit shifted out 
is a one or if the resulting high-order dividend 
byte is greater than or egual to the divisor, the 



divisor is subtracted from the high byte of the 
dividend. As the low-order bits of the dividend 
are vacated by the shift left, the resulting 
partial-guotient bits are rotated in. Thus, the 
quotient and the low byte of the dividend 
occupy the same byte, which saves register 
space, code, and execution time. 
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9. Arithmetic 


Z8ASM 




2.0 










Routines 


LOC 


OBJ 


CODE 


STMT SOURCE STATEMENT 




(Continued) 










1 


ARITH 


MODULE 














2 


CONSTANT 














3 


COUNT 




RO 












4 


DIVISOR 


R1 












5 


DIVIDEND HI 


R2 












6 


DIVIDEND LO 


R3 












7 


GLOBAL 








P 


0000 






8 


DIVIDE 


PROCEDURE 












9 


I***************************************************** 












10 


Purpose = To perform a 16-bit by 8-bit unsigned 












1 1 




binary division. 












12 


















13 


Input 


= 


}1 = 8-bit divisor 












14 






}R2 = 16-bit dividend 












15 


















16 


Output = 


^3 = 8-bit quotient 












17 




R2 = 8-bit remainder 












18 




Carry flag = 1 if overflow 












19 






= if no overflow 












20 


**X****#*#**tt*********ft******X***********************t 












21 


ENTRY 








P 


0000 


OC 


08 


22 




Id COUNT, #8 !LOOP COUNTER! 












23 


















24 


.'CHECK 


IF RESULT 


WILL FIT IN 8 BITS! 




P 


0002 


A2 


12 


25 




cp DIVISOR, DIVIDEND HI 




P 


0004 


BB 


02 


26 
27 


IWON'T 


jr UGT,LOOP JCARRY = (FOR RLC)! 
FIT. OVERFLOW! 




P 


0006 


DF 




28 




SCF 


!CARRY = 1 ! 




P 


0007 


AF 




29 
30 
31 


LOOP: 


ret 
•RESULT 


WILL FIT. GO AHEAD WITH DIVISION! 




P 


0008 


10 


E3 


32 




RLC DIVIDEND_LO ! DIVIDEND * 2! 




P 


000A 


10 


E2 


33 




RLC DIVIDEND_HI 




P 


oooc 


7B 


04 


34 




jr c,subt 




P 


000E 


A2 


12 


35 




cp DIVISOR, DIVIDEND_HI 




P 


0010 


BB 


03 


36 




jr UGT,next '.CARRY = 0! 




P 


0012 


22 


21 


37 


subt : 


SUB DIVIDEND_HI, DIVISOR 




P 


0014 


DF 




38 




SCF 


!TO BE SHIFTED INTO RESULT! 




P 


0015 


OA 


F1 


39 


next : 


djnz COUNT, LOOP !no flags affected! 












40 


















41 


•ALL 


DONE! 






P 


0017 


10 


E3 


42 




RLC DIVIDEND_LO 












43 






!CARRY = 0: no overflow! 




P 


0019 


AF 




44 




ret 






P 


001A 






45 
46 


END DIVIDE 
END ARITH 





ERRORS 
ASSEMBLY COMPLETE 



15 instructions 

26 bytes 

124.5 /is (average) 



SECTION 

10 



Conclusion 

This Application Note has focused on ways 
in which the Z8 microcomputer can easily yet 
effectively solve various application problems. 
In particular, the many sample routines 



illustrated in this document should aid the 
reader in using the Z8 to greater advantage. 
The major features of the Z8 have been 
described so that the user can continue to 
expand and explore the Z8's repertoire of uses. 
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Get powerful microprocessor performance 

by using the Z80. With 158 instructions it offers more 
flexibility than other /uPs, plus 8080 code compatibility. 



The Z80 8-bit microprocessor combines all the 
processing power of the 8080 with 80 additional 
instructions. And to keep chip count to a minimum, 
many of the peripheral circuits necessary for 8080 
systems have been built into the Z80. All members 
of the Z80 family are built with n-channel, silicon- 
gate, depletion-load technology; function at single- 
phase clock rates of 4 MHz; require just a 5-V supply; 
and have TTL-compatible inputs and outputs. 

The circuit family consists of the Z80-CPU and the 
following peripherals: a counter-timer circuit (CTC), 
a parallel input/output circuit (PIO), a direct- 
memory-access controller (DMA), and a serial 
input/output circuit (SIO), as well as a group of 
support boards (Table 1). All the circuits are available 
in 2.5 or 4-MHz versions, ceramic packages, and 
extended temperature ranges. All are housed in 40-pin 
DIPs, except the CTC, which comes in a 28-pin DIP. 

All peripheral circuits can be daisy-chained for 
priority interrupt control. Since most peripheral 
circuits necessary for system operation are built into 
the Z80, a minimum system consists of the Z80, a 
system clock, a power-on reset circuit and any memory 
and peripheral circuits desired (Fig. 1). At the system 
level, the /xP supports vectored priority-interrupt 
structures without any extra hardware. 

Interfaces to the Z80 are simple 

Although the Z80 maintains timing and control- 
signal compatibility with the 8080, it is not pin- 
compatible. All output lines can sink 1.8 mA at 0.4 
V — the equivalent of one standard TTL load. 

Three major buses from the chip— the 16-bit address 
bus, the 8-bit bidirectional data bus and a 13-line 
control bus— account for 37 of the Z80's 40 pins (Fig. 2). 
The other three pins are for power, ground and the 
single-phase clock. Unlike the 8080, the Z80 needs no 
status latch or clock, and interrupt vectoring and 
dynamic-memory refresh are completely supported 
within the /xP itself. 

The 13 control lines are actually subdivided into 
three control buses: system control (six lines), /xP 

Authors: Ralph Ungerman, (former Zilog 
Vice President); Bernard Peuto (Direc- 
tor of Engineering). 
Reprinted with permission of Electronic Design . 2-2 



Table 1. Z80 system components 



Part # 


Description 


Price * * 
100 qty 


Z80-CPU 


8-bit CPU, 2.5 MHz * 


$26.50 


Z80-CTC 


Counter/timer, 2,5 MHz * 


$17.00 


2BO-PIO 


Parallel I/O, 2.5 MHz * 


$11.00 


Z80-DMA Direct mem. access, 2.5 MHz * 


$38.00 


Z80-SIO 


Serial I/O, 2.5 MHz * 


NA 


Support boards 


unit qty 


MCB 


Microcomputer board — kit 


$435, 




—assembled 


$495. 


MDG 


Memory/floppy-disc controller 


$795, 


RMB 


RAM memory board 


$750. 


IOB 


Input/output board 


$350. 


PMB 


PROM/ROM memory board 


$395. 


PPB/ 






EPROM 


EPROM programmer (for 2708) 


$475. 


PPB/ 






PROM 


PROM programmer 
(for 7620, 7640) 






$475, 


CPB/ 






ROM 


Combination programmer 


$575. 


VDB 


Video-display board 


$475. 



4-MHz versions of these parts are available. 
to 70-C ratings in plastic packages 



irl 



5V 

Q 



5V 



^T 1 



Z80 

CPU 



A0-A9 I 



CE 2 



U 

■<z£3SM inn/ 



LLL 



IORQ B/A 

_ Z80-PI0 



PORT A PORT B 



1 T 



C/D-*M,| 



OUTPUT 
DATA 



INPUT 1 
0A1A ! ! 



1. A minima! Z80 system can be built with the 11P, an 
oscillator, some memory and an I/O port such as the PIO. 
Just a power supply and reset circuit must be added. 



- SYSTEM 
CONTROL 




2. The three major buses on the Z80 are an address bus, a 
data bus and a control bus. The control bus can be split 
into three smaller buses— one for system control, one for 
processor control and one for bus control. 



control (five lines), and ^P-bus control (two lines). One 
bus-contr ol line functions as a bus-request line 
(BUSRQ), which is an input that requests not only 
the mP's address and data buses, but also the memory- 
request, I/O-request, read-data and write-data lines 
of the system-control bus to go to a high-impedance 
state so that other devices can use the bus. The other 
bus-c ontrol line , an output signal called bus-acknowl- 
edge (BUSAK), goes high to indicate when the lines 
go into a high-impedance third state. 

All sixsystem-control signals are outputs from the 
juP. An Mi line (machine cycle 1) goes Low to indicate 
when the ^P is in the op-code-fetc h part o f an 
instruction. The memory-request line (MREQ) goes 
Low when the address bus holds a valid address for 
a memo ry-read or write operation. An I/O-request line 
(IORQ) goes Low to indicate that the lower byte of 
the address bus holds a valid I/O-port address for an 
I/O-read or write operation. 

Memory-read and memory-write lines (RD and WR) 
are also active when Low. RD indicates that the n? 
wants to read data from a memory or I/O device, while 
WR indicates that the data bus holds data to be stored 
in the addressed location. W hen the sixth system- 
control line, a refresh signal (RFSH), goes Low, it 



indicates that the lower seven bits of the address bus 
contain a r efresh address for dynamic memories, so 
the current MREQ signal should be used to do a refresh 
read to all dynamic memory. 

The five yuP-control lines consist of one output signal 
and four input lines. All lines are active when Low. 
The only output is the halt line, which indicates when 
the /aP has executed a software HALT instruction and 
is waiting for either a nonmaskable or maskable 
interrupt. While halted, the ^P automatically executes 
NOP instructio ns to m aintain the memory refresh. 
The wait input (WAIT) indicates to the ^P that the 
addressed memory or I/O device isn't ready for a data 
transfer (the juP will enter wait states for as long as 
this line is Low). This line allows memory or peripher- 
al of any speed to be synchronized with the Z80. 

To re set the /jP or initialize it once it is on, the 
RESET line can be pulled Low. When pulled Low, it 
forces the Z80's program counter to 00i 6 , disables the 
interrupt-enable flip-flop, sets register I to 00i 6 , sets 
register R to 00i 6 , and sets the interrupt node to 0. 

The last two lines are the interrupt-request (INT) 
and nonmaska ble-in terrupt (NMI) inputs. When 
pulled Low, the INT line interrupts the processor at 
the end of the current instruction if the software- 
controlled i nterrupt -enable flip-flop (IFF) is enabled, 
and if the BUSRQ line is High. Each time t he ^P 
accepts an interrupt, an acknowledge signal (IORQ 
during an Mi time) is sent out at the beginning of the 
next i nstru ction cycle. 

The NMI line is a negati ve-ed ge triggered input, has 
a higher priority than the INT line, and is recognized 
at the end of the current instruction regardless of the 
IFF state. When triggered, it forces the Z80 to begin 
execution at location 0066i 6 after saving the current 
contents of the program counter in an external stack. 

Interrupts and flags add flexibility 

Three interrupt modes are available to the program- 
mer. Mode permits the interrupting device to insert 
any instruction on the data bus and have the ^P 
execute it. Mode 1 has the ^P automatically execute 
a restart to location 0038i 6 — no external hardware is 
required (the contents of the program counter are 
pushed onto the internal stack). 

Mode 2, the most powerful, permits an indirect call 
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3. By daisy-chaining the peripheral support circuits, any 

number of peripheral chips can be added to thisZ80-based 
process-control system. The device closest to the nP has 



the highest priority interrupt. Just 16 IC packages are 
needed to build this data-acquisition subsystem; and of 
the 16, nine are memories. 



to any memory location. In this mode, the /uP forms 
the indirect address from the upper byte of the I 
register and eight bits that are supplied by the 
interrupting device. 

Two identical 8-bit flag registers (F and F') are part 
of the Z80. Six of the bits in each register can be used 
as conditions for jump, call or return instructions; 
they are set or reset by various /aP operations. Both 
the F and F' registers have four testable flag bits and 
two nontestable bits. The four testable bits are the 
Carry flag, Zero flag, Negative-sign flag and 
Parity /overflow flag. 

The Carry flag contains carry from the highest- 
order accumulator bit— add, subtract, shift and rotate 
instructions can alter its state. If an operation loads 
a zero into the accumulator, the Zero flag gets set. 
Otherwise, it is reset. Used with signed numbers, the 
Negative-sign flag gets set if the result of an operation 
is negative (bit 7 of the accumulator is the sign bit). 
The dual-purpose Parity /overflow bit gets set when 
the parity of the result in the accumulator for a logic 



operation is even, or is used to indicate overflow when 
signed 2's complement arithmetic is performed. 

The two nontestable bits are Half-carry and Sub- 
tract flags. The Half -carry flag is a BCD-carry or 
borrow result from the least-significant four bits of 
the operation. (When a DAA instruction is used, this 
flag corrects the result of a previously packed decimal- 
add or subtract operation.) The Subtract flag corrects 
BCD operations by helping identify the previous 
instruction; The correction differs for addition and 
subtraction. 

Shifting operations can be performed on any reg- 
ister or memory location rather than just on the 
accumulator. What's more, I/O operations can also 
be done with any register, rather than just the 
accumulator. Sixteen-bit direct loads and stores can 
be sent to the BC-register pair, the DE pair or the 
IX or IY registers— instead of just the HL as in the 
8080. Consequently, the number of exchange and 
register-move operations is reduced considerably. 
Also, 16-bit arithmetic operations using the HL pair 
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Z80 microprocessor architecture 

Built into the Z80 microprocessor are all bus- 
control, memory-control, and timing signals in addi- 
tion to eight general-purpose 16-bit registers and an 
arithmetic-and-logic unit (ALU). The Z80 is upward- 
compatible with the Intel 8080A 1 and 8085 /J>s. 

All the 8080 registers are duplicated within the Z80 
and, in addition to the eight 8-bit registers (A, F, B, 
C, D, E, H and L) of the 8080, there is an alternate 
set (A', F', B', C, D', E', IT and L') and several other 
special-purpose registers. The additional registers 
include two 16-bit index registers (IX and IY), an 8- 
bit interrupt-vector register (I) and an 8-bit memory- 
refresh register (R). Also carried forward from the 
8080 register set are the 16-bit stack pointer and the 
16-bit program counter (PC). 

Normally, all instructions reference the main reg- 
ister set, and alternate registers are accessed via two 
exchange commands that swap register contents in 
the banks. One command, exchanges the accumulator 
and register flags, while another instruction, ex- 
changes the other six general-purpose registers. Since 
both instructions are single-byte, minimum-execu- 
tion-time instructions, a complete swap can be done 
in four clock cycles (1 /is for a 4-MHz clock). These 
commands and registers are very handy for rapid 
single-level interrupt handling. 

The Z80's two index registers have no direct cor- 
ollary in the 8080 architecture, but in operation they 
resemble the single index register in the 6800 /iP. 2 
Instructions using this mode such as the accumulator- 
load command [LD A, (IX + 7)] contain a single-byte 
offset field (+7, in this case). The effective address 
of the operand is the sum of the offset and the IX- 
register contents. This addressing mode is particular- 
ly convenient for table references, multibyte entries 
or for passing a pointer to a group of subroutine 
parameters. The offset byte is interpreted by the Z80 
as a 2's complement number, so both positive and 
negative indexing is possible. 

A special feature of the Z80 is its ability to refresh 
dynamic memory automatically. Its memory-refresh 
register acts as a 7-bit counter that is incremented 
after every op-code fetch. After the fetch, the R- 
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register contents are loaded onto the low-order seven 
bits of the address bus, and a status line on the 
processor goes low to indicate the presence of a valid 
refresh count. Because this entire process takes place 
while the op code is decoded internally, it never 
interferes with any other /aP activity on the bus. 

The I register forms the high-order eight bits of an 
address. When an interrupt occurs and the Z80 is in 
the vectored mode, the lower order eight bits are 
supplied by an interrupting peripheral. In response 
to the interrupt, the ^P does an Indirect Call instruc- 
tion with the composite address. All the support chips 
have corresponding registers that store the low-order 
eight bits and supply them to the Z80 when the 
interrupt is acknowledged. 

Able to perform 12 basic operations— add, subtract, 
AND, OR, Ex-OR, compare, test-bit, reset-bit, set-bit, 
increment, decrement, and left or right-shift and 
rotate (arithmetic or logic)— the ALU communicates 
with the registers and external-data bus by means of 
a buffered internal bus. As each instruction is fetched 
from memory, it is loaded into the instruction register 
and decoded by the control section, which supplies all 
the control signals for the Z80's subsystems. 



have been expanded over the 8080's to include add with 
carry and subtract with borrow. 

Software gives the Z80 horsepower 

Many of the instructions available only in the Z80 
support the manipulation of multibyte blocks of data 
—a great plus in data communications and text 
manipulation. For instance, a block-move instruction 
takes data from the memory location specified by the 
HL-register pair, deposits them in the location speci- 
fied by the DE pair, increments the HL and DE 
registers and then decrements the BC pair, which is 
assumed to hold a byte counter for the operation. This 



instruction can be executed in a single cycle or repeat 
sequence. Decrementing the HL and DE addresses is 
also possible. 

By using the block move command, the ijP can 
transfer bytes of data at 5.25 ^s/byte (for a 4-MHz 
clock). Block operations are also available for memory 
searches and I/O operations. And shift and rotate 
operations have been enhanced. For decimal 
arithmetic, 4-bit shifts through the accumulator can 
greatly speed up BCD multiplication and division, and 
bit-manipulation instructions permit fast access to 
any bit in either the external memory or an internal 
register. 

Other enhancements of the instruction set include 
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Software capabilities of the Z80 

Able to execute over 150 different instructions, 
including all 78 of the 8080A command set, the Z80 
features seven basic families of instructions: load- 
and-exchange, block-transfer-and-search, arithmetic 
and logic, bit-manipulation (set, reset and test), jump, 
call-and-return, input/output, and basic /uP-control 
commands. In all, the Z80 can recognize 696 op codes 
—244 are the codes of the 8080A. 

Load instructions move data internally between /jlF 
registers or between the registers and external memo- 
ry. All these instructions must specify a source 
location, from which data are to be moved, and a 
destination location. Block-transfer instructions per- 
mit any block of memory to be moved to any other 
location. Search commands let any block of external 
memory be examined for any 8-bit character. Once 
the character is found, the instruction is terminated. 

The ALU instructions operate on data held in the 
accumulator and other general-purpose registers or 
external memory. Results are held in the accumulator, 
and appropriate flags are set. Bit-manipulation com- 
mands allow any bit in the accumulator, any general- 
purpose register or any external memory location to 
be set, reset or tested with a single instruction. Jump, 
Call and Return instructions are used to transfer 
between various locations in the program. 

I/O instructions permit a wide range of transfers 
between external memory locations or general- 
purpose Z80 registers and external I/O devices. In 
either case, the port number is provided on the lower 
eight bits of the address bus during any I/O operation. 
Also, the basic /xP-control commands include such 
instructions as setting or resetting the interrupt- 
enable flip-flop or setting the mode of interrupt 
response. 

In addition to the seven addressing modes of the 
8080— direct, register, register indirect, modified 
page 0, extended, implied and immediate— the Z80 has 
three more addressing modes: relative, indexed, and 
bit addressing— that can be used. 

A special byte-call instruction lets the Z80 program 
proceed to any of eight locations in page of the 
memory. This modified page addressing allows a 
single byte to specify a complete 16-bit address, which 
saves memory space. 

Relative addressing lets the Z80 use the byte follow- 
ing the op code to specify a displacement from the 
current program-counter value. The displacement 
value is in 2's-complement form, which permits up 
to a +127 or -128 byte displacement. Extended 
addressing includes two bytes of address in the 
instruction. 

Index registers can also be used as part of the 
address. In the indexed addressing mode, a byte of 
data following the op code is a displacement value that 
must be added to the specified index register (the op 
code indicates which register) to form a memory 
pointer. Also available is an implied addressing mode 
in which the op code uses the contents of one Z80 
register or more as the operands. The last addressing 
mode lets the Z80 access any memory location or /uP 
register and permits any bit to be set, reset or tested. 



Mnemonic Description 

8-bit load instructions 

LD r, r' Load register r with r' 

LD r, n Load register r with n 

LD r, (HL) Load r with location (HL) 

LD r, (IX+d) Load r with location (IX+d) 

LD r, (lY+d) Load r with location (lY+d) 

LD(HL),r Load location HLwith*r 

LD (IX+d), r Load location IX+d from register r 

LD (lY+d), r Load location lY+d from register r 

LD (HL), n Load location HL with value n 

LD (IX+d), n Load location IX+d with n 

LD (lY+d), n Load location lY+d with n 

LD A, (BC) Load AC with location BC 

LD A, (DE) Load AC with location DE 

LD A, (nn) Load AC with location nn 

LD (BC), A Load location BC with AC 

LD (DE), A Load location DE with AC 

LD (nn), A Load location nn with AC 

LD A, I Load register A from I 

LD A, R Load AC with register R 

LD I, A Load register I with AC 

LD R, A Load register R with AC 

16-bit load instructions 

LD dd, nn Load registers dd with nn 

LD IX, nn Load register IX with nn 

LD IY, nn Load register IY with nn 

LD HL, (nn) Load L with contents of location 

nn and H with (nn+1) 
LD dd, (nn) Load registers dd with location nn 

LD IX, (nn) Load IX with location nn 

LD IY, (nn) Same but for IY 

LD (nn), HL Load location nn with HL 

LD (nn), dd Load location (nn) with register pair dd 

LD (nn), IX Same but for IX 

LD (nn), IY Same but for I Y 

LD SP, HL Load stack pointer from HL 

LD SP, IX Load stack pointer from IX 

LD SP, IY Load stack pointer from IY 

PUSH qq Load register pair qq onto stack 

PUSH IX Load IX onto stack 

PUSH IY Load IY onto stack 

POP qq Load register pair qq with top of stack 

POP IX Load IX with top of stack 

POP IY Load IY with top of stack 

Exchange, transfer and search instructions 
EX DE, HL Exchange contents of DE & HL 

EX AF, A' F' Exchange contents of AF & A' F' 

EXX Exchange all six general purpose registers 

with alternates 
EX (SP), HL Exchange stack pointer contents with 

HL contents 
EX (SP), IX Same but use IX register 

EX (SP), IY Same but use IY register 

LDI Load (HL) into DE, increment DE and 

HL, decrement BC 
LDIR Same but loop until (BC) = O 

LDD Load location (PE) with location (HL) and 

decrement DE, HL and BC 
LDDR Same but loop until (BC) =0 

CPI Compare contents of AC with (HL), set Z 

flat if =, increment HL and decrement 

BC 
CPIR Same but repeat until BC = O 

CP s Compare operand s with AC 

CPD Same as CPI but decrement HL 

CPDR Same as CPIR but decrement HL 

8-bit arithmetic and logic instructions 
ADD A, r Add contents of r to AC 

ADD A, n Add byte n to AC 

ADDA, (HL) Add contents of HL to AC 
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ADD A, (IX+d) 


Add location (IX+d) to AC 


Jump, c all and return instructions 


ADD A, (lY+d) 


Same but (lY+d) 


JP nn 


Unconditional jump to location nn 


ADC A, s 


Add with carry operand s to AC 


JP cc, nn 


If condition cc True, do a JP nn 


SUBs 


Subtract contents of r, n, HL, IX+d or 




otherwise continue 




lY+d from AC 


JR e 


Unconditional jump to PC+e 


SBCs 


Same but also subtract carry flag 


JR C,'e 


If C = continue. If C = 1 do JR e 


ANDs 


Logic AND of operand s and AC 


JR NC,e 


Reverse of JR c, e 


ORs 


Same but OR with AC 


JR Z, e 


If Z = continue. If Z = 1 do JR e 


XOR s 


Same but EX-OR with AC 


JR NZ, e 


Reverse of JR Z, e 


INCr 


Increment register r 


JP(HL) 


Load PC from (HL) 


INC(HL) 


Increment location (HL) 


JP (IX) 


Load PC from (IX) 


INC (IX+d) 


Same but use (IX+d) 


JP (IY) 


Load PC from ( I Y) 


INC(IY+d) 


Same but use (lY+d) 


DJNZ, e 


Decrement register B and jump 


DECm 


Decrement operand m 




relative if B = 


'•6-bit Arithmetic instructions 


CALLnn 


Unconditional call subroutine at 








location nn 


ADD HL f ss 


Add register pair ss to HL 


CALLcc, nn 


Call subroutine at location nn if 


ADC HL, ss 


Same but include carry flag 




condition cc is True 


SBC HL, ss 


From HL subtract contents of ss and 


RET 


Return from subroutine 




carry flag 


RETcc 


If cc false continue, otherwise do RET 


ADD IX, pp 


Add register pair pp to IX 


RETI 


Return from interrupt 


ADD IY, rr 


Same but use rr and IY 


RETN 


Return from nonmaskable interrupt 


INCss 


Increment register pair ss 


RSTp 


Store PC in stack, load in PC H 
and restart vector in PCj_ 


INC IX 


Increment IX register 




INC IY 


Same but IY register 






DECss 


Decrement register pair ss 


Input/output 


instructions 


DEC IX 


Same but IX register 


IN A, n 


Load AC with input from device n 


DEC IY 


Same but IY register 


IN r, (C) 


Load r with input from device C 






INI 


Store contents of location specified by C 


General purpose 


arithmetic & control instructions 




in address specified by HL, decrement 


DAA 


Decimal adjust accumulator 




B and increment HL 


CPL 


Complement (AC) 


INIR 


Same but repeat until B = 


NEG 


Complement (AC) and add 1 


IND 


Same as INI but decrement HL too 


CCF 


Complement carry flag 


INDR 


Same as INIR but decrement H L too 


SCF 


Set carry flag = 1 


OUT n, A 


Load output port (n) with AC 


NOP 


No operation 


OUT (C), r 


Load output port (C) with register r 


HALT 


Halt, wait for interrupt or reset 


OUTI 


Load output port (C) with location (HL) 


Dl 


Disable interrupts 




and increment HLand decrement B 


El 


Enable interrupts 


OTIR 


Same but repeat until B = 


IM0 


Set jUP to interrupt mode 


OUTD 


Same as OUTI but decrement HL 


IM1 


Set jUP to interrupt mode 1 


OTDR 


Same as OTIR but decrement HL 


IM2 


Set (J.P to interrupt mode 2 






Rotate and shift instructions 






RLCA 


Rotate AC left 


Notes 




RLA 


Same but include carry flag 


b represents 


a 3-bit code that indicates position of the bit to 


RRCA 


Rotate AC right 


be modified 


RRA 


Same but include carry flag 


cc represents 


a 3-bit code that indicates which of eight condi- 


RLCr 


Rotate register r left 


tion codes are to be used 


RLC (HL) 


Rotate location (HL) left 










d is an 8-bit ottset value 


RLC (IX+d) 


Same but location (IX+d) 






RLC(IY+d) 


Same but location (lY+d) 


dd refers to register pairs BC, DC, HL or the stack pointer 


RL m 


Same as any RLC but include 


e represents 


a signed two's complement number between 




carry flag 


-126 and +129 


RRC m 


Same as RLC but shift right 


m is an 8-bit 


number 


RR m 


Same as RL m but shift right 


n is an 8-bit number 


SLAs 


Shift left (any RLC register) 






SRAs 


Same but shift right and keep MSB 


nn refers to two 8-bit bytes 


SRLs 


Same as SLA but shift right 


p represents 


one of eight restart vector locations on page 


RLD 


Simultaneous 4-bit rotate from AC|_to 
L, Lto Hand H to AC L 


pp refers to 


register pairs BC, DE, the IX register or the stack 




pointer. 




RRD 


Simultaneous 4-bit rotate from AC^_ to 
H, H to Land Lto AC|_ 

test instructions 


qq refers to t 


egister pairs AF, BC, DE or HL 


Bit set, reset and 


r or r' refers to registers A, B, C, D, E, H or L or their 


BITb, r 


Test bit b of register r 


alternates' 




BITb, (HL) 


Test bit b of location (HL) 


rr refers to r 


egister pairs BC, DE, the IY register or the stack 


BITb, (IX+d) 


Test bit b of location (IX+d) 


pointer 




BITb, (lY+d) 


Test bit b of location (lY+d) 


s refers to e' 


ther the r registers, the n data word or the con- 


SETb, r 


Set bit b in register r to 1 


tents of 


locations specified by the contents of the HL, 


SETb, (HL) 


Same but use contents of location HL 


IX+d or lY+d registers 


SETb, (IX+d) 


Same but use contents of location IX+d 


ss refers to register pairs Be, 0E\ HL or the stack pointer 


SETb, (lY+d) 


Same but use contents of location lY+d 






RESb, s 


Reset bit b of operand m 
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4. With two parallel, 8-bit I/O ports, the PIO circuit (a) can 
use either of the ports in a parallel system or on a line-by- 
line basis for 16 separate I/O lines. Inside each port, five 
control registers are loaded by the Z80 before operation to 
initialize the port (b). 



the decimal-adjust command, which now works after 
subtract as well as add operations. Negate-instruc- 
tions and looping commands are also part of the set. 
The looping instruction decrements the B register and 
takes a relative branch if that register has not reached 
zero. Other operations are shown in the box on Z80 
software (see page 58). 

Put the Z80 to work 

With the four basic Z80 peripheral circuits described 
virtually any high-performance microcomputer can be 
constructed. For example, a process-control system 
can be built around the Z80, as shown in Fig. 3. The 
peripherals handled by the Z80 controller include 
three parallel input/output circuits and one 
counter/timer. The PIOs handle a 16-key keyboard, 
a printer, a multichannel a/d converter and 16 control 
lines. Because the peripheral chips can be daisy- 
chained, a priority interrupt structure can be formed 
with little or no software or hardware overhead. Using 
the interrupt mode, the requesting PIO causes the juP 
to go to a service routine, and, after the routine, a 
special instruction— return-from-interrupt — goes 
back to the PIO and allows the /aP to service lower- 
priority interrupts. 

All support chips have two lines for daisy-chaining 
—the Interrupt-enable-in (IEI) and Interrupt-enable- 
out (IEO). Since a CTC is used in the controller to 



relieve the Z80 from doing timing loops, software 
overhead is minimized. For the controller of Fig. 3, 
14 ICs are needed — and nine of them are memories 
(2048 bytes of ROM and 4096 bytes of RAM). 

The Z80-PIO, a parallel-interface controller, has two 
8-bit ports and provides TTL-compatible interfaces 
(Fig. 4a). Port A has four possible modes of operation: 
byte output, byte input, byte bidirectional bus and bit. 
Port B has all the modes except byte bidirectional. 
The port I/O logic consists of handshake control and 
six registers (Fig. 4b): an 8-bit input register, an 8- 
bit output register, a 2-bit mode-control register, an 
8-bit mask register, an 8-bit I/O-select register and 
a 2-bit mask-control register. The last three are used 
only when the port is programmed to operate in the 
bit mode. Of the 40 pins on the PIO, 24 are required 
by the port and CPU buses, six more for fiP interfac- 
ing, three for interrupt control, four for handshaking 
the I/O ports and three for power, ground and the 
single-phase clock. 

Four of the six internal registers are loaded by the 
Z80 for characteristic programming. The contents of 
the 2-bit mode-control register determine which of the 
four PIO operating modes is to be used. Similarly, the 
2-bit mask-control register specifies the active state 
(High or Low) of any peripheral-interface lines which 
are to be monitored. It also permits an interrupt to 
be generated when all unmasked pins are active (AND 
condition) or when any unmasked pin is active (OR 
condition). The code loaded into the mask register 
determines which peripheral-device interface pins are 
to be monitored for the specified status condition. And 
the code held in the I/O-select register determines 
which pins are inputs or outputs during bit-mode 
operation. The other two registers hold incoming or 
outgoing data. 

To relieve some software overhead in timing situ- 
ations, the CTC provides four channels of program- 
mable timing and counting functions that can be set 
with software (Fig. 5). Each channel operates in either 
a timer or counter mode, and programmable inter- 
rupts can occur on counter or timer states. Other 
features include a readable down counter, a selectable 
16 or 256 clock prescaler for each timer, a selectable 
positive or negative trigger for timer initiation and 
automatic reload of counter or timer constants. In 
addition three channels have zero count/timeout out- 
puts capable of driving Darlington transistors. 

Each channel has two registers, both eight bits long 
and loaded by the jliP. One register, the time-constant 
register, loads the preset value into the down counter. 
The other, called a channel-control register, contains 
the mode and condition information for channel opera- 
tion. Also included in each channel are an 8-bit down 
counter and an 8-bit prescaler. The counter is decre- 
mented by the prescaler in the timer mode and by 
the clock-trigger input in the counter mode. 

Of the 28 pins on the CTC, eight connect to the data 
bus, seven to the control lines, three handle interrupt 
control and three are required for power, ground and 
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5. Each CTC provides four channels of counting/timing 
capability with an 8-bit counter on each channel (a). There 
is a control register for each channel and a programmable 
8-bit prescaler (b). 



the single-phase clock. Three of the four input chan- 
nels have one input and one output line and the fourth 
channel has only an input line. 

Speed up data transfer with DMA 

One of the interface circuits, a direct-memory- 
access controller, is designed to effect the high-speed 
transfer of a block of data between any two ports in 
a Z80 system and can also be used with other ^Ps. 
The circuit is a programmable, single-channel device 
that provides all address, timing and control signals 
for the data transfer (Fig. 6). Also, the DMA circuit 
can search a block of data for a particular, bit- 
maskable byte, with or without transferring the data. 
Capable of transfer-only, search-only or search-and- 
transfer operations at up to 1.2 Mbyte/s, the circuit 
can automatically increment or decrement the port 
address from a programmed starting address. 

Four communications modes are available on the 
chip— a byte-at-a-time mode that transfers one byte 
per request, a burst mode that lets the transfer 
continue as long as ports are ready, a continuous mode 
that locks out the /xP until the operation is completed, 
and a transparent mode that steals refresh cycles. 
When the circuit finds a match or finishes a transfer, 
it can be programmed to generate an interrupt. Or 
a complete repeat cycle can be programmed for 
automatic repeat or repeat on command. A built-in 
block counter can generate a signal when a certain 



number of bytes has been transferred—without halt- 
ing the transfer. 

Inside the DMA controller are bus-interface circuits 
for both the data and address buses, logic and registers 
to control parameters of the circuit, and address and 
byte-count circuitry to generate port addresses. There 
are also provisions for incrementing or decrementing 
the address, timing circuitry for adjusting the 
read/write timing of both ports being addressed, and 
compare logic that permits a byte-matching operation 
(if a match is encountered, a flag is set in the DMA's 
status r egister). Also built-in is the interrupt and 
BUSRQ logic, which includes a control register that 
specifies conditions for the chip to generate an inter- 
rupt, all the priori ty-en codi ng logic to select between 
generation of an INT or BUSRQ output, and an 
interrupt-vector register for automatic vectoring to an 
interrupt-service routine. 

Of the 40 pins on the DMA controller, 24 are needed 
for the address and data bus, and five are needed for 
the /*P control bus. Eight more handle the interrupt 
control and timing, and three more are necessary for 
power, ground and clock inputs. 

For serial communications, the serial-input/output 
circuit (SIO) provides two full duplex programmable 
channels capable of handling asynchronous, 
synchronous, and synchronous-bit protocols (IBM 
Bisync, HDLC and SDLC). It can also generate cyclic- 
redundancy check codes in any synchronous mode. The 
SIO has four independent serial ports— two for trans- 
mitting and two for receiving (Fig. 7). Asynchronous 
data with 5, 6, 7 or 8 bits and 1, l-# or 2-stop bits 
as well as even, odd or no-parity generation or check- 
ing can be handled. 

The circuit has X 1, 16, 32 and 64 clock modes and 
data rates from to 600 kHz. The transmitter sections 
have eight modem-control lines, quadruple buffers on 
receiver data and error registers, and double buffers 
on the transmitter sections. The bus-I/O control block 
includes the logic for selecting channels and registers, 
read/write control, and control of special timing for 
interrupt-acknowledge cycles. Interrupt logic includes 
the daisy-chain provision as well as two special 8-bit 
control registers to handle the various interrupt op- 
tions, as well as an 8-bit vector register for interrupt 
response. 

Three receive buffers allow enough time for inter- 
rupt servicing of fast data rates. The receiver-shift 
register is controlled by the receive-control logic, 
which includes two 8-bit registers for receive-mode 
selection and options. There are two more 8-bit reg- 
isters for programmable-sync characters. The 
external-status register is an 8-bit, read-only register 
that indicates the state of the modem-control pins as 
well as several internal-status conditions. An internal- 
status register also indicates the state of the SIO. Each 
channel has its own receive, transmit and status- 
register banks. 

Now that you are familiar with all the basic system- 
building blocks, you can mold them with software into 
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a working system. Because of the Z80's rich instruc- 
tion set, assembling software programs by hand can 
be too complicated for most applications; you should 
use either a dedicated development system or time- 
sharing service. 

Development systems speed software 

The Z80 development systems and the software 
available from Zilog include several large dedicated 
units that permit hardware or software development, 
or both (Table 2). Also available are assemblers, 
compilers and time-sharing services as well as Basic 
and PLZ. (Cobol and Fortran will be available soon.) 

All program statements in the development systems 
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6. The direct-memory-access controller has three classes 
of operation: transfer-only, search-only or search-and- 
transfer. Any device on the system bus can be controlled 
by the DMA; internal counters keep track of source and 
destination addresses. 



are handled by a text editor and stored in a dual floppy- 
disc file management system. Once filed, the program 
is ready for testing and can be translated by an 
assembler or compiler into code for the Z80. The code 
can be tested by a hardware/software debug package 
that provides interrogation, control and tracing 
capabilities. 

In the monitor mode the system has four operating 
environments: file, edit, debug and assemble. The file 
capabilities are pretty standard types of features- 
storing records on disc, pulling records from disc, 
changing records and saving the new results. The 
debug and assembler features of the development 
system offer some pretty powerful capabilities. With 
the debug commands, you can set up breakpoints, 
compare blocks of memory and trace an operation. 

In the debug mode, for instance, system trans- 
actions can be loaded into a special memory as the 
program executes in real time. And, once any user- 
defined condition has occurred (such as the setting of 
bit 6 of port 8Bi 6 or reading from address 21C8i 6 ), the 
program execution can be suspended and the system 
can re-enter the monitor mode. A complete record of 
the last 256 transactions just prior to program termi- 
nation is in the system memory and available to the 
user. 

The main assembler in the development system 
supports the following features: macros, conditional 
assembly, the ability to assemble a large file and a 
sorted-symbol table with cross reference. All these 
options as well as the printing and listing options are 
available by setting parameters at the time of as- 
sembly. A relocatable assembler with I/O man- 
agement provides relocatable code and has a linking 
loader. These permit you also to specify other files 
that should be included within the current file being 
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7. Two independent full-duplex serial I/O channels are 

built into the SIO. Either channel can be programmed to 



operate in asynchronous or synchronous modes, includ- 
ing BiSync and HDLC/SDLC. 
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Table 2. Hardware and software support 



Type Price 
unit qty. 


Name 


Description 


Systems $8990 

$6990 
$6990 
$5990 


Z80*hardware & 
software 
development 
system 

Z80-software 

development 

system 

Z80-hardware 

development 

system 

Z80-microcomputer 

system 


3 kbytes ROM, 1 kbyte RAM for system monitor; 

16 kbyte RAM; real-time debug module; dual 

floppy discs; in-circuit emulator; RS-232 or current 

loop interface; software and user's manuals; extra card 

slots; 2 chassis system. Universal interface to printers, PROM 

program mers, etc. 

Same as above, except no in-circuit emulation capability. 

Same as first system, except no universal interface. 

Dual floppy disc system in single chassis 
containing any combination of Z80 board 
products (MCB, MDC, etc.) 


Resident N.A. 
software 

N.A. 
N.A. 

Cross N.A. 
software 


OSZ80-operating 
system for Z80 
development 
systems and 
MCB family 

BASIC interpreter 

PLZ-Zilog resident 

programming 

language 

Z80 cross assembler 

Z80-PLM language 
compiler 


Assembler: translates assembly language 

mnemonics into machine language, Includes 

macro's, conditional assembly, the ability 

to assemble programs of virtually any length and sorted 

symbol tables with complete cross-reference listings. 

Relocating assembler and linking loader: Facility for linking 

programs which have been assembled independently and executing 

Editor environment: allows the user to input and modify texts, 

such as, assembly language source programs. 

File environment: controls and manipulates disc files that the 

user creates while writing, debugging and executing 

programs. 

Debug environment: allows the user to load, test and save programs 

using an assortment of debugging aids. 

This program supports an interpretive language that 
allows translation into machine code at execution time on a state- 
ment-by-statement basis. 

From relocatable assembly to high-level system 
programming: 

• allows access to architecture of Z80 

• compiles efficient code 

• easy to translate to machine language 

Two levels of the language allow tailoring to programming task 

needs. 

ANSII 16-Bit Fortran and PLI version available. 

Full PLM language compiler produces Z80 



assembled so you can combine programs. 

The text editor in the system includes many com- 
mands (for more than many full minicomputer edi- 
tors) to help you manipulate the source files. Although 
it is a line editor (the pointer always indicates the 
beginning of a line), some string-oriented commands 
are available. Automatic paging permits you to edit 
files that are larger than available memory work 
space. Put and Get commands help you copy sections 
from one disc file to another or insert them into a 
program. Over 20 commands in the editor permit text 
repeats, alterations, storage, line-number printing 
and macro capabilities. 

To develop higher-level language programs, you can 
use a Basic interpreter. This permits programs to be 
written and debugged interactively. Also made for 
resident use is PLZ, a procedure-oriented language 



with a syntactic and semantic style that blends Algol, 
PL/1 and Pascal. It permits access to the Z80 architec- 
ture, can compile efficient code and is easy to translate 
into machine code. Two levels are available: PLZ Level 
I combines assembly language with statements neces- 
sary to create relocatable program modules; Level II 
is similar to a high-level systems language in which 
single statements can substitute for sequences of 
assembly-language statements. ■■ 
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DESIGNING A MICROPROCESSOR 
DRIVEN MULTIPURPOSE 
PERIPHERAL CONTROLLER 



Requisites of adaptability to mix/match combinations of I/O 
devices, operation with existing software, and intelligence 
formulated the design of a microprocessor based multifunction 
controller architecture 



Richard F. Binder Modular Computer Systems, Incorporated, Fort Lauderdale, Florida 



^M equirements for a revised generation of peripheral 
controllers became apparent while the ModComp 
classic computer series was still in the conceptual 
stage of design. System packaging was based on card- 
edge pluggable wirewrapped boards for modularity 
and ease of maintenance. To devote a full board space 
(approximately 550 integrated circuits) to a single 
card reader or line printer controller seemed unreason- 
able; this configuration would waste space and entail 
extra cost. The decision therefore was made to pack- 
age several such low performance controllers on one 
board. Specifying that the design approach would be 
toward a multiported controller adaptable to many 
different devices in mix/match configuration avoided 
the problem of choosing which controllers to conjoin. 
Also, the new controller had to operate with existing 
software and would therefore require some intelli- 
gence. For example, the existing card reader controller 
is fully buffered and can transfer data in a direct 
12-bit card image; in a transitional 8-bit code called 
"half -ASCII," packed either one or two bytes per word; 
or in any 8-bit code downloaded by the host mini- 
computer, again packed one or two bytes per word. 
It performs multipunch detection while translating to 
8-bit codes. Other controllers to be reimplemented 
are similarly sophisticated. 
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Clearly, a microprocessor is the way to package the 
requisite intelligence en a single board. This approach 
relieves the designer of complex hardware and/or 
custom microcode design; a microprocessor's firmware 
is generally more maintainable than microcode fitted 
to custom logic. Also, interfacing to future devices should 
be easier. 



General Architecture 

Since a microprocessor based controller is extremely 
slow in relation to a controller implemented with 
discrete logic, the designer must take into consideration 
the microprocessor's response time. This response de- 
ficiency can be concealed for the most part under 
the overhead of the host's interrupt-driven input/out- 
put (i/o) bus without slowing down the overall 
system. Several nearly instant system responses are 
still required, however, such as the setting of control- 
ler busy status for the addressed port in response to 
a transfer-initiate command. These responses are gen- 
erated by hardware in the form of a programmed logic 
array (pla) to set status latches. A Z80A microproces- 
sor computes all other status which are stored as 16- 

Reprinted with permission from Computer Design— April, 1979 issue 
Copyright 1979 by Computer Design Publishing Corp. 



bit words in four 4-word by 4-bit register files for 
access by the host's software. Fig 1 is a simplified 
block diagram of the multifunction controller's final 
design. 

Actual execution of commanded operations is of 
course carried out by the microprocessor; all com- 
mands and data are loaded by the host into the 
command/data (c/d) first in, first out (fifo) buffer. 
This buffer allows the host to issue several commands 
in rapid sequence. The microprocessor fetches the com- 
mands from the buffer one at a time and processes 
each as required. Even though four independent de- 
vices can be controlled by this design, the c/d fifo 
buffer need not be very deep in storage capacity; the 
interrupt-driven i/o bus makes it possible for the 
microprocessor to control to some extent the rate at 
which it receives commands by controlling the rate 
at which it generates interrupts. The c/d fifo buffer 
in the controller is 16 words deep by 21 bits wide 
(16 bits for the data and 5 bits to identify the com- 
mand's function and destination within the controller). 

Similarly, since four independent devices can be con- 
trolled, the handling of one device cannot wait for 
the i/o's response to an interrupt for another device. 
Therefore, three request FIFO buffers are loaded by the 



microprocessor for the host: service interrupt (si), data 
interrupt (di), and direct memory processor (dmp). 
The first two requests are vectored in the host for 
software processing, while the third activates concur- 
rent hardware in the host's i/o processor itself. As 
each request is needed, the microprocessor loads the 
request's source identification word into the appropriate 
request FIFO buffer. The request FIFO buffers are 
,unloaded by the host at its own rate, and the micro- 
processor is thereby freed to attend to other functions. 
Another use of the request FIFO buffers is made by 
device firmware sets (tasks) which must be able to 
"stack" more than one request of the same type; a 
single register for each request type prohibits such 
stacking. 

The microprocessor selected had to be fast enough 
to support the required system throughput. Tentative 
short benchmark routines were coded for the 8080A, 
Z80, 9900, and 6800. One of the coded benchmarks 
was a routine to fetch the 21 -bit contents of the 
c/d fifo buffer and transfer control to the appropriate 
task. The following table gives an approximate com- 
parison of various microprocessors' performance derived 
from a sample routine based on the controller's firm- 



MULTIFUNCTION CONTROLLER 




Fig 1 Controller block diagram. Layout exhibits straightforward bus architecture. Distinguishing feature is address- 
ing scheme consisting of displacement register (DREG) and peripheral-select PLA. This hardware makes possible 
firmware-transparent bank switching 
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Microprocessor 


Clock Periods 


Time 


8080A-2 


167 at 320 ns 


53.4 fis 


Z80A 


92 at 250 ns 


23.0 /is 


9900 


114 at 300 ns 


34.2 fis 


68B00 


58 at 500 ns 


29.0 fis 



Calculations based upon these short routines indi- 
cated that of the machines coded for, only the Z80A 
would be adequate. All further design was tailored ex- 
plicitly for the Z80A; no detailed hardware or firm- 
ware design was produced for the other machines. 
(These values were attained by a designer most 
familiar with the Z80. Greater familiarity with other 
microprocessors might lessen the disparity in perfor- 
mance, but the Z80's powerful instruction set, vectored 
interrupt scheme, and twin register sets made it the 
undisputed choice for this application. ) 

The four device ports (numbered to 3) must be 
adaptable to both serial and parallel devices. Original- 
ly, the multifunction controller specification called 
for support of a card reader, three types of line printers 
(two parallel and one serial), a paper tape punch, 
a paper tape reader, a serial console terminal, and 
a full-duplex RS-232-C asynchronous channel with full 
modem control and fully programmable parameters. 
A typical configuration might include a card reader 



in port 0, a line printer in port 1, and an asynchronous 
channel in ports 2 and 3. Packaging requirements 
specified a total of 80 signal pins for all four ports. 
This constraint, together with an analysis of all the 
parallel devices, led to a 20-bit port configured as eight 
bidirectional bits for data transfer, four bidirectional 
bits for status or control (handshaking, etc), seven 
input bits for status or control, and one output bit 
for control (Fig 2). 

Of the seven input bits, two can be programmed 
(Online for signal inversion, and one of these two can 
be connected to either a pullup or pulldown resistor 
for device power sensing. The two groups of bidirec- 
tional bits, including control of their buffers, can be 
reprogrammed online. (For a card reader, all bits are 
input; for a line printer, all bits are output.) This 
interface configuration can be made to handle most 
common 8-bit devices. For serial devices, the 20-pin 
limitation requires that the parallel buffers be re- 
moved and replaced with a universal synchronous/ 
asynchronous receiver/transmitter (usart), as well 
as appropriate line drivers and receivers. 

The Z80A-PIO parallel i/o controller chip provides 
the required bit-programmable port capability (Fig 2), 
but it has only two 8-bit ports. Six pio chips are 
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Fig 2 Parallel interface 
port. Each parallel port 
interface consists of 3-state 
buffers connected to port's 
PIOs to provide each task 
with ability to program 
interface to suit its own re- 
quirements. For uniformity, 
all buffers are Intel 8226 
even if used only in one 
direction 



2-15 



needed to drive four 20-bit controller ports. Since 
one and one-half pio chips provide 24 bits, the extra 
four bits control the buffers connected to the pro- 
grammable bits. The two shared pio controllers handle 
only data paths, and therefore are not connected to 
the microprocessor's interrupt system. All six chips are 
configured to operate in bit control mode; hence, their 
handshake lines are not used. Handshaking is accom- 
plished by addressing various port bits. Each controller 
port has one complete Pio chip that can generate any 
needed interrupt. 

For serial applications, all 24 bits are available to 
be programmed as required to best support the spe- 
cialized serial hardware. To minimize serial hard- 
ware, the decision was made to restrict console tasks 
to port or 1, and the channel task to ports 2 and 
3 together. A serial line printer uses the console 
hardware. A USART is connected so that it is handled 
as though it were an external device. Serial handling 
may seem somewhat clumsy, but the hardware involved 
in the microprocessor's bus structure is simplified since 
there is no need to interface directly to a specific chip. 
This approach also helps to standardize the tasks in 
their port handling. The Z80-SIO serial i/o chip was 
not yet available when this controller was designed. 
Examination of the preliminary sio specification, how- 
ever, indicated that use of the sio would seriously 
complicate the controller's internal structure; even if 
the IC had been available, it probably would not have 
been used. (The area in question is the displacement 
register, which will be discussed later.) 

Some of the devices to be controlled require either 
timeouts or cyclic testing of status. These timing func- 
tions are triggered by a Z80A-CTC (counter-timer cir- 
cuit) ; its four channels are allocated one to each 
controller port, and are used as timers for intervals 
.up to 16.4 ms (the longest timeout possible with the 
4-MHz clock). Longer timeouts are made by firmware 
counting of ctc interrupts. 

A seventh, or frontend, pio is used between the micro- 
processor and the host's i/o to load the various re- 
quests into the appropriate FIFO buffers and to provide 
a vectored interrupt signal to the microprocessor when 
the c/d FIFO contains information to be processed. 
Sixteen-bit status and data words for the host are 
stored in separate 4x4 register files whose inputs 
are i/o mapped for loading by the microprocessor. 
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Firmware Considerations 

In order to be able to switch among several concurrent 
activities, the firmware is designed as a multitasking 
operating system consisting of an executive program 
and the various device handlers, or tasks. The executive 
is always present, while tasks are added as needed 
by plugging in read-only memory (rom) sets. 

Executive Program 

The executive occupies 768 bytes of ROM and 256 bytes 
of random-access memory (ram), and has three pri- 
mary functions: to initialize the system, control time- 



sharing, and provide executive services available to all 
tasks. System initialization is performed at power-up 
[Fig 3(a)]. The first routine executed sets up the 
parameters required for the controller as a whole and 
initializes the CTC since the latter function is needed 
only once for all four ports. A loop is then entered 
which executes four times, once for each port. Task- 
not-present status is loaded into the status register file, 
interrupt entry vectors are loaded into the Pio assigned 
to the port represented by the pass count of the loop 
(port on the first pass, port 1 on the second, etc), 
and a test is made to determine whether the port's 
task ROM is present. If not, its command entry dedi- 
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Fig 3 Simplified main controller flow. Controller and four tasks 
are initialized under control of executive program (a). Program 
then enters polling loop (b), which provides for priority interrupt 
service and for one task's round-robin polling service on each 
pass. In idle condition, loop executes in 11 /*s/pass, ensuring 
reasonably rapid interrupt response 



cated location in RAM is loaded with a common ignore- 
this-command return. If it is present, the first 10 ROM 
locations — containing pio interrupt, ctc interrupt, com- 
mand interrupt, data transfer interrupt, and polling 
service entry addresses — are transferred to dedicated 
locations in either executive or task ram. Control is 
then transferred to an initializer within the task itself; 
this routine sets up the port PlOs and CTC as required 
for the particular task, and generates and loads valid 
status to replace the initial status loaded by the execu- 
tive. Control is then returned to the executive initializer, 
which processes all four ports in this manner before 
enabling the hardware to respond to the i/o. 



Once initialized, the system enters an idle loop 
whose function is to control timesharing among the 
tasks present. This idle loop, called the polling loop 
[Fig 3(b)], enables a task in two ways: interrupt 
service (priority enabling) and polling service (round- 
robin enabling) . Any activity must begin with an in- 
terrupt, either from a task's ctc port or from the 
outside world (the host or the device connected to the 
particular port). A ctc or device pio interrupt is vec- 
tored to the relevant task routine, which takes ap- 
propriate action. An interrupt from the host's i/o, 
through the frontend pio, is vectored to an executive 
routine which extracts the contents of the current c/d 
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FIFO buffer location, decides whether it is a command 
or data, and transfers control to the task routine 
whose address is in the pertinent dedicated location. 
Whichever task routine is activated completes its action 
and returns control to the polling loop. The task ac- 
tivity in question may need service of a type which 
cannot be triggered by further interrupts (such as 
emptying a buffer asynchronously with its filling, to a 
device that does not handshake). Such service is acti- 
vated by the setting of a dedicated location, called the 
polling flag, to any nonzero value. 

Each task has its own polling flag and an associated 
polling entry dedicated location. During each pass of 
the polling loop, an interrupt window is opened for 
2 fxs. If no interrupt is pending, or upon return from 
the servicing of an interrupt, the loop tests one port's 
polling flag. If the flag is zero, the port number is 
incremented and the polling loop restarts, opening 
the interrupt window. Each port is tested once every 
four passes through the loop. If the polling flag is non- 
zero, the loop fetches the address of the task polling 
routine from the dedicated location and calls that routine. 
The task routine takes the action for which it has 
been set up and resets the polling flag if no further 
polling service is required, and then returns to the 
polling loop, which continues as before. Note that in- 
terrupt service always receives priority over polling 
service; this arrangement provides the fastest possible 
response to the outside world, and is guaranteed by 
specifying that all interrupt routines must enable the 
interrupt before returning to the polling loop. If another 
interrupt is pending, it is serviced immediately. 

To minimize both interrupt and polling service 
times, the system takes advantage of the Z80's two 
sets of working registers. One set contains registers A, 
B, C, D, E, H, and L; the second set is a duplicate 
of the first. A single instruction (exx) will exchange 
all but A with their duplicates, and another instruction 
(ex, af, af') will exchange A and the machine's flag 
register. The latter instruction is not used in the multi- 
function controller — A is considered volatile by each 
routine. The polling loop does the context swap for 
polling routines, but interrupt routines must do the 
swap themselves. One set is dedicated to the polling 
loop; register B contains the number of the next port 
whose polling flag will be tested, register pair DE 
contains the address of the polling flag in memory, 
and register pair HL contains the address of the poll- 
ing routine being called. The second register set is 
available for use by any task or executive service 
routine. The Z80 also has two index registers, IX and 
IY, but these registers are not used in the controller 
because indexed instructions suffer a 1-^s/instruction 
time penalty. 

The executive provides several services to any task 
in the form of callable subroutines. These services 
perform the functions of 

(1) Decoding commands that a task has determined 
to be of a control nature, such as controller interrupt 
connection, data transfer termination, etc. Appropriate 
action is taken and control is returned to the calling 
routine if required. 



(2) Generating one request for a data transfer eitker 
to or from the i/o. This request may be either a 
DI or a dmp request; the executive service routine tests 
current controller parameters to decide which type is 
proper. 

(3) Initializing or terminating the host's dmp hard- 
ware by generating specialized dmp requests for these 
functions. 

(4) Requesting startup or shutdown service of the 
host's software by generating an si, and optionally 
resetting controller busy when setting the Si. 

(5) Reinitializing the calling task exactly as is done 
at power-up. Primarily a diagnostic tool, this function 
is essentially free — the same routines are used in both 
cases. 

Primary value of the executive services is to reduce 
the size of the tasks, since each task is limited to 768 
bytes of ROM and 256 bytes of ram. An added ad- 
vantage lies in the fact that a task designer need not 
reinvent the wheel by designing all the common func- 
tions again for each new task; the effort required to 
implement new tasks is thereby minimized. 

As mentioned above, tasks are limited in size. A 
more serious problem, however, is the necessity that 
any task (with certain specific exceptions) be installed 
into any port position. It is clear that the various port 
memory areas will have different starting addresses. 
A conventional software program designed to be loaded 
into various areas of memory (relocatable software) 
is accompanied by a list of locations within the program 
which must be modified upon loading to reflect the 
program's starting address. Once programmed, however, 
a ROM set cannot be changed; so it would seem that 
each task must come in four versions, one for each 
port. This constraint was considered unacceptable; 
stocking of all the different ROM sets would create 
problems for both manufacturer and user. The solution 
to this problem lies in relocatable firmware, which 
can be implemented by memory mapping, of which 
bank switching is a simplified form. Two address bits 
(A10 and All) are used to select one of the four 
tasks, and the most significant address bit (A15) is 
used to control whether the bank switch is invoked 
[Fig 4(a)]. All tasks, then, can originate at memory 
address zero. It is possible to address any memory 
location in absolute mode (A15 = 1), but only the 
selected task is accessible in relative mode (A15 = 
0) . The executive is always addressed absolutely to 
make its services available to any task. The addresses 
of those services are assembled with each task as 
"external" equates. 

Located in executive RAM, the push-pop stack is 
addressed absolutely. Pio and ctc interrupt dedicated 
locations are also in executive ram, but these locations 
are addressed relatively so that accesses to the same 
relative address in each task will be routed to the 
proper absolute address by the bank switching control 
hardware. The interrupts themselves are routed through 
the same absolute addresses by the vectors loaded into 
the hardware. 
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Fig 4 Memory displacement (bank switching). Task/executive selection is ac- 
complished by multiplexing A10 and A11 with contents of DREG. In absolute mode 
(A15 = 1), any area of memory is accessible; in relative mode (A15 = 0), only 
selected task is accessible. Interrupt dedicated locations in executive RAM are 
addressed by multiplexing A1 and A2 with DREG. Addresses generated by task 
firmware access same actual locations as does hardware interrupt entry. Displace- 
ment scheme makes it unnecessary for task to know its port address. In (b), 
firmware-generated address of 4000 may be actual address of 4000, 4002, 4004, or 
4006, as controlled by DREG. Hardware interrupt response (c) concatenates interrupt 
register and actual vector supplied by interrupting peripheral to produce addresses 
in executive RAM that correspond to those produced by DREG-modified firmware 
addressing 



Task Routines 

Tasks consist of a series of short routines whose func- 
tions fall into the following categories: initialization, 
command and data transfer handling, request gen- 
eration, and device handling. During initialization, the 
executive passes control to an initializing routine in 
the task. This initializer is responsible for setting 
each of its PlOs with the required i/o bit patterns 
and interrupt enables, and its ctc port with a timeout 
and an enable if the ctc is to be used. It initializes 
task oriented, dedicated locations as required, and it 
generates and loads the proper controller status to 
the status register file for access by the host. Control 
is then returned to the executive. This initialization 
scheme provides the only reasonable means of con- 
troller setup — by the tasks themselves. 

Commands to a task are received from the c/d FIFO 
buffer. A FIFO interrupt, recognized by the frontend 
PIO, triggers the executive routine which fetches the 
FIFO contents and transfers control to the task's com- 
mand handler. The command handler then decides 
what type of action is requested by examining the 
16-bit data pattern of the command, making use of 
executive service if required, and takes that action. 
Control is then returned to the executive. Note that 
online task routines must execute as fast as possible 
in order to make way for other tasks which may be 



time dependent. In one design case, compliance with 
this general rule required that an interrupt routine 
be divided into two portions; the second half of this 
routine is triggered by programming a PIO to generate 
an interrupt when an unused output bit is written to 
the true state. This splitting of a low priority interrupt 
routine permits higher priority activity to intervene 
while guaranteeing that the second half will execute 
much sooner than if it were a polling routine. 

At the transfer rates for which the multifunction 
controller is designed, direct memory access (dma) adds 
unnecessary hardware and complicates such capabilities 
as character recognition and/or processing. Therefore, 
data transfers are handled in much the same manner 
as are commands. One of the extra c/d FIFO bits 
specifies the direction of the transfer; output data from 
the host are either output directly to the device or 
loaded into a buffer for output later, when the device 
is ready. Buffered data output generally is triggered 
by polling service, whereas direct output always is 
a result of a transfer requested by a device interrupt 
routine signifying that the device is ready. Input data 
may also be buffered or not, as applicable to a par- 
ticular device; for example, the card reader task buffers 
its data to protect the i/o against overflow. Input data 
are loaded into the data register file. When the host 
accepts the data in response to the controller's data 
request, that transfer is loaded into the c/d fifo buffer 



2-19 







463 


*********** 






469 


* INTH * 






470 , 


*********** 






471 , 








472 , 

473 

474 


ENTER ON INTERRUPT FROM MOT HOLD 


022E 


D9 


NTH EXX ;N0T-H0LD INTRPT IF GET HERE 


022 F 


210C03 


475 


INTH1 LD HL, CSTAT 


0232 


7E 


476 


LD A,(HL> ;FETCH CSTAT 


0233 


OF 


L77 


RRCA ;D0, D1 = D1 


0234 


OF 


478 


RRCA 


0235 


07 


479 


RLCA 


0236 


17 


480 


RLA 


0237 


11 


481 


LD (HL),A ;SAVE NEW CSTAT 


0238 


CD0A02 


482 


CALL LPSTA ;L0AD MOST-RECENT STATUS TO 4X4'S 


023B 


3E97 


483 


LD A,097H 


023D 


D383 


48^ 


OUT (PI0BC),A ;SET UP FOR INTRPT ON LINE STROBE 


023F 


3EFB 


485 


LD A,0FBH 


241 


0383 


486 


OUT (PI0BC),A 






487 


STRIP PAGE PORTION OF BOF INTRPT HANDLER ADDRESS 


0243 


3E4 F 


488 


LD A,INTB-INTB/256*256 






489 


THE ABOVE MATHEMATICAL TECHNIQUE TAKES ADVANTAGE OF THE 






490 


FACT THAT ALL INTRPT ROUTINES ARE LOCATED IN THE SAME 






491 


MEMORY PAGE - ONLY THE LOWER ORDER ADDRESS BYTE NEEDS 






492 


TO BE LOADED. THIS TECHNIQUE IS USED THROUGHOUT THE 






493 


TASK IN ORDER TO CONSERVE EXECUTION TIME AND MEMORY 






494 


SPACE . 


0245 


320040 


495 


LD (PI0BV),A ;CHANGE PENTV BACK TO "B0F"-R0UT INE 


0248 


320603 


496 


LD <P0LF),A ;SET POLLING FLAG 


024B 


D9 


497 


EXX ; E X I T 


024C 


FB 


498 


£1 


024D 


ED4D 


499 


RETI 


Fig 5 


Typical 


nterrupt routine. Routine monitors controller status change from HOLD to READY 


when 


operator depresses 


RUN switch. It reports new status to host, sets PIO to interrupt when next 


line feed occurs 


, and loac 


s interrupt dedicated location in executive RAM with address of routine 


which 


tests for 


bottom-of- 


form status. It sets polling flag — if controller is busy, data transfer com- 


mences (polling 


vector wi 


1 have been set to address data-to-printer routine); if not, service inter- 


rupt 


s generated to noti 


fy host that printer is available (polling vector will address Sl-generation 


routine). Manipulation of 


DO in internal controller status word (CSTAT) copies enable bit stored 


in D1 


into status that will be read by host if SI is made 



as though it were an output. Upon recognizing this 
input transfer, the firmware ignores the FIFO data and 
proceeds to ready the next transfer. 

Data requests may be generated by several mechan- 
isms. An interrupt routine servicing a device whose 
data rate is controlled by the device (eg, a terminal, 
through a usart) generates a request when it has 
data for input or when the device requires output. A 
polling routine emptying an input buffer generates 
requests as long as there are data in the buffer. Finally, 
an output data transfer interrupt routine filling a buffer 
generates a request every time it is triggered by the 
receipt of a transfer, after loading the just-received 
data into its buffer. 

Data are transferred to an output device by writing 
the data to the half pio and then writing a one followed 
by a zero to another output bit assigned as the strobe 



line. If a handshake is required, the strobe is set true 
and allowed to remain set until an acceptance is 
signalled by the device. Data from an input device 
are read from the half Pio and then accepted, if the 
device requires a response, by strobing in the same 
manner as for output. The CTC is used for two func- 
tions: cyclic activity and single-shot timeouts. Most 
cyclic activity tests and updates status for devices whose 
status can change during periods of controller inac- 
tivity. Such changes are often due to operator inter- 
vention. Single-shot timeouts are required for devices 
which take long periods to execute some function or 
functions and do not signal the completion of such 
functions. A currently supported paper tape punch, for 
example, takes a full second to run up to speed when 
started; it is left running for 10 s after the completion 
of a transfer to avoid repeated up and down cycles 
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and the consequent startup delays. Several concurrent 
timeouts may be controlled by a common clock handler 
routine, and this activity by no means precludes cyclic 
functions as well. 



Hardware Architecture 

The memory bank switching function is the central 
capability of the hardware, and is implemented with 
a single* 2-bit register called the displacement register 
(dreg). Input to dreg is data bus bits Dl and D2 
[Fig 4(a)]. This register is loaded either by an 
executive routine or hardware interrupt routine. The 
executive routine which fetches the c/d fifo contents 
loads two of the extra FIFO bits into dreg by a mapped 
memory write. The register is addressed as though it 
were a memory location; hence, any firmware has the 
ability to load it, but tasks normally do not do so. 
The two loaded bits are a binary encode of the port 
selected by the host's controller address bus, and when 
used as A10 and All, they select the specified task's 
memory area. Hardware interrupt response loads Dl 
and D2 into dreg using the interrupting device's vector 
to select the task whose device made the interrupt. 
Dedicated interrupt entry locations are allocated to 
provide the proper vectors. It is this function which 
precluded use of the Sio. The sio generates a series 
of vectors for a given port, so that bits 1 and 2 cannot 
be used for port selection. 

dreg outputs are multiplexed with A10 and All 
from the microprocessor, and the multiplexer is steered 
by A15. When A15 is a zero (relative mode), the 
multiplexer gates dreg's outputs to the controller's 
internal address bus, and any one of the four task 
areas can be accessed. When A15 is a one (absolute 
mode), the microprocessor's actual address is used, 
and any area of memory can be addressed. The execu- 
tive is always addressed absolutely; certain tasks, 
which occupy more than one port and are always 
installed in the same port location, are also addressed 
absolutely to avoid the necessity of constantly reload- 
ing dreg when executing different subroutines. 

DREG addresses not only memory but also most other 
port oriented hardware in the controller. This scheme 
is necessary to speed execution times; if a task were 
required to recognize its port address, and compute 
and load the addresses of all its devices, most routines 
would become unreasonably long. To avoid this prob- 
lem, all PlOs and the CTC are selected by a peripheral- 
select pla, which is steered by a combination of ad- 
dress bits to 7 and the dreg outputs, dreg steers 
both data and status register files and most of the port 
oriented hardware in the front end. This hardware 
includes a multiplexer whose inputs are the controller's 
option-selection switches, and several registers used 
to control interrupt generation to the host. 

In addition, dreg supplies a port selection function 
in addressing the executive RAM, but in this case dreg's 
outputs are multiplexed with address bits Al and A2. 



Vectors are loaded into the various ports' interrupting 
peripherals, two locations apart, and these two address 
bits select which port's dedicated location is addressed 
when the firmware uses relative mode. For example, 
the firmware addresses location 4000 (hexadecimal), 
and any one of the four locations — 4000 (equivalent 
to C000), 4002, 4004, or 4006— is accessed as con- 
trolled by dreg [Fig 4(b)]. The firmware cannot 
address these locations directly in relative mode since 
dreg overlays the programmed address. During a hard- 
ware interrupt response, location COxx is addressed with 
the XX being supplied by the interrupting peripheral 
[Fig 4(c)]. Port 0's pio supplies 00 to address C000, 
port l's pio addresses C002, etc, with A15 forcing 
absolute addressing to one of four locations which all 
appear as 4000 to the firmware. This method (Fig 5) 
is used for all interrupt vectoring. Extended use of 
dreg makes it unnecessary for a task ever to know 
in which port it is installed, thereby significantly in- 
creasing the overall throughput of the controller. 

Summary 

Although the multifunction controller is limited to an 
aggregate throughput of from 4000 to 8000 bytes/s, 
depending upon configuration, this performance exceeds 
the requirements of the peripheral devices it is designed 
to handle. The microprocessor based design offers satis- 
factory solutions to most problems and objectives of 
a multipurpose intelligent peripheral controller: it 
allows reasonably fast response to the host, enables 
the system designer to mix or match peripherals, and 
provides an adaptable interface for additional periph- 
erals. It can easily be configured for installation into 
a system, and is relatively inexpensive to manufacture 
and simple to service. 
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INTRODUCTION Interrupts provide a means of processing 
Information on a random or asynchronous 
basis. The Z80 CPU and peripheral family 
support interrupts using a daisy-chain 
approach. As opposed to para I lei priority 
resolution, the daisy chain uses an 
efficient, minimal-hardware method of priori- 
tizing multiple Interrupting devices. In 
addition, a parallel priority resolution 
scheme can be configured with the Z80 through 
the use of a priority encoder and other 
external hardware. 

Coupled with the powerful vectored interrupt 
capabilities of the Z80, this approach allows 



the system designer great flexibility in 
Implementing an interrupt driven system. 

This document describes the Z80 CPU interrupt 
process and evaluates the design of the 
daisy-chain interrupt scheme. The reader can 
refer to the following documents for addi- 
tional information: 

Z80 Assembly Language Programming 

Manual (03-0002-01) 

Z80/Z80A CPU Technical Manual (03-0029-01) 

Z80/Z80A SI0 Technical Manual (03-3033-01) 

Z80/Z80A PI0 Technical Manual (03-0008-01) 

Microcomputer Components Data 

Book (03-8032-01) 



Z80 CPU 

INTERRUPT 

PROCESSING 



The Z80 uses two types of interrupt s: mask- 
able (INT input) and non-maskable (NMI 
input). Maskable interrupts may be nested. 
The simplest maskable interrupt implementa- 
tion does not provide for the nesting of 
interrupts, thereby obligating an interrupt 
service routine to complete Its processing 
and return to the main program before another 
Interrupt can be serviced. With nested 
Interrupts, an interrupt service routine can 
be interrupted either by an interrupt that 
invokes the same routine (reentrant type) or 
by a higher priority interrupt that invokes a 
different interrupt service routine. The Z80 
family components allow the user to Implement 
a powerful interrupt-drlven system utilizing 
these concepts. 

When both types of interrupts are employed, 
the Z80 CPU will service them in a specific 
sequence. Both the TNT and NMI inputs are 
sampled by the CPU on the rising edge of CLK 
in the last T state of the last Machi ne (M) 
cycle of any instruction. However, if BUSRQ 
is active at the same time, it will be 
processed before any interrupts. Figure 1 
illustrates the Z80 interrupt service 
sequence. 




Figure 1 . Z80 Flow Diagram Interrupt Sequence 



Non-Maskable The non-maskable interrupt (NMI) is different 
Interrupts from the maskable Interrupt in several 

respects. NMI Is always enabled and cannot 
be disabled by the programmer. It is 
employed when very fast response Is desired 
Independent of the maskable interrupt status 



and can be used for i nter rupt conditions like 
a power fail detect. NMI is an edge-sens I- 
tlve s ignal that has a lower pr iori ty than 
BUSRQ and higher priority than INT. When the 
CPU acknowledges an occurrence of NMI, the 
processor begins a normal opcode fetch. How- 
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ever, the data read from memory is Ignored 
and instead the CPU restarts its operation 
from location 66H. The restart operation 
involves pushing the Program Counter onto the 
stack, jumping to location 66H, and continu- 
ing to process there. During this time, the 
status of the maskable interrupt condition is 



preserved and maskable interrupts are dis- 
abled, until either an El instruction is 
executed or a RETN instruction is used to 
exit the NMi service routine. 
The RETN instruction is discussed in* detail 
in the Z80 CPU Technical Manua l. Figure 2 
shows the timing used for NMI interrupts. 
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Figure 2. Non-maskable Interrupt Request Operation 



Maskab I e 
I nterrupts 



Maskable interrupts (INT) are acknowledged 
with a lower priority than the NMI but a I low 
the programmer more flexibility. INT is 
enabled under software control by way of the 
El instruction and disabled via the PI ?n- 
struction. When the Z80 CPU samples INT and 
it is active, the processor begins an inter- 
rupt acknowledge cycle so long as BUSRQ and 
NMI are not active. The processor does not 
use an interrupt acknowledge signal but 
instead issues the acknowledge by executing a 



CLK 



special Ml cycle. During an interr upt 
acknowledge cycle, RD is inactive, IORQ is 
active, and two wait states are automatical ly 
added. 

Since the Z80 peripheral devices have logic 
to interpret this special cycle with no 
additional external circuitry, a minimal 
amount of hardware is needed by the system 
and there is no loss in efficiency. Figure 3 
shows the detailed timing for the Z80 CPU 
interrupt acknowledge cycle. 
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Figure 3. Interrupt Acknowledge Cycle 
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There are also three modes of operation for 
servicing maskable interrupts. These are Mode 
0, Mode 1, and Mode 2. Any particular mode 



is selected by the programmer using the IM 
instruction. Figure 4 illustrates the 
processing sequence for each interrupt mode. 



MODEO 



MODE 1 



MODE 2 



DISABLE INTERRUPTS 
IFF1. IFF2 = 



READ 1ST BYTE 
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(Ml, FORQ LOW) 



READ NEXT BYTE 
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DISABLE INTERRUPTS 
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RET 

STACK -» PC 



YES 



^ CALL OR RST > 
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DISABLE INTERRUPTS 
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RETI 
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Figure 4. Maskable Interrupt Sequences 



Maskable In the maskable interrupt Mode (as with the 
Interrupt 8080 interrupt response mode), the interrupt- 
Mode * n 9 device places an instruction on the data 
bus for execution by the Z80 CPU. The in- 
struction used is normally a Restart (RST) 
instruction, since this is an efficient one- 
byte call to any of eight subroutines located 
in the first 64 bytes of memory. (Each sub- 
routine is a maximum of eight bytes.) How- 
ever, any instruction may be given to the Z80 
CPU. 

The first byte of a multibyte instruction Is 
read during the interrupt acknowledge cycle. 
Subsequent bytes are read in by normal memory 
read cycles. The Program Counter remains at 
its pre interrupt state, and the user must 
Insure that memory will not respond to these 



read sequences, since the instruction must 
come from the interrupt hardware. Timing for 
the additional bytes of a multibyte instruc- 
tion Is the same as for a single byte In- 
struction (see NMI in Figure 2). 

When an interrupt is recognized by the CPU, 
succeeding Interrupts are automatically 
disabled. An El Instruction can be executed 
anytime after the interrupt sequence begins. 
The subroutine can then be interrupted, 
a I lowing nested interrupts to be used. The 
nesting process may proceed to any level as 
long as a I I pertinent data is saved and 
restored correctly. 



Upon RESET, the CPU automatically sets 
interrupt Mode 0. 



Maskable 
I nterrupt 
Mode 1 



Interrupt Mode 1 provides minimally complex 
peripherals access to interrupt processing. 
It Is similar to the NMI interrupt, except 
that the CPU automatical ly CALLs to location 



38H instead of 66H. As with the NMI, the CPU 
pushes the Program Counter onto the stack 
automatical ly (Figure 2). 
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Maskable 
Interrupt 
Mode 2 
(Vectored 
Interrupts) 



The Z80 CPU interrupt vectoring structure 
a I lows the peripheral device to identify the 
starting location of the interrupt service 
routine. 

Mode 2 is the most powerful of the three 
maskable interrupt modes. It allows an 
indirect cal I to any memory location by a 
single 8-bit vector supplied by the periph- 
eral. In this mode, the peripheral generat- 
ing the interrupt places the vector onto the 
data bus in response to an interrupt ack- 
nowledge. The vector then becomes the least 
significant eight bits of the 16-bit indirect 
pointer, whereas the I register in the CPU 
forms the most significant eight bits. This 
address points to an even address in the 
vector table which then becomes the starting 
address of the interrupt service routine. 
Interrupt processing thus starts at an 
arbitrary 16-bit address, al lowing any loca- 
tion in memory to begin the service routine. 
Since the vector is used to identify two 
adjacent bytes that form a 16-bit address, 
the CPU requires an even starting address for 
the vector ! s low byte. Figure 5 shows the 
sequence of events for processing vectored 
interrupts. 

The I register is loaded by the user from the 
A register. There is no restriction on its 



value other than its pointing to a valid 
memory location. 
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NOTES 

1 Interrupt vector generated by peripheral is read by CPU dur- 
ing interrupt acknowledge cycle 

2 Vector combined with I register contents form 16-bit memory 
address pointing to vector table. 

3 Two bytes are read sequentially from vector table These 2 
bytes are read into PC. 

4 Processor control is transferred to interrupt service routine 
and execution continues. 

Figure 5. Vector Processing Sequence 



Return from When execution of the interrupt service 
Maskable routine is complete, return to the main 
Interrupt program (or another service routine) occurs 
differently in each mode. In Mode 0, the 
method of return depends on which instruction 
was executed by the CPU. If an RST instruc- 
tion is used, a simple RET suffices. In Mode 
1, the CPU treats the interrupt as a CALL 
instruction, so an RET is used. Mode 2, 
however, uses the vector information from the 
peripheral chip to identify the source of the 



recognized interrupt, and a method of reset- 
ting the peripheral's interrupt condition 
must be found. This is accomplished by using 
the RET I instruction. If Mode 2 is used by 
the programmer, the RETI instruction must be 
executed in order to utilize the daisy chain 
properly. Figure 6 shows the RETI instruc- 
tion timing for the Z80 CPU. A more complete 
description of how RETI affects the periph- 
erals is given in Chapter 3. 



T 3 T 4 




M1- 



\ 



f 



\ 



f 



■\ r 



\ 



/ 



D0-D7 



XDC 



xzx 



\ 



f 



\ r 



(HIGH) 



Figure 6. Return From Interrupt Timing (RETI) for Mode 2 Interrupts 
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Halt Exit Whenever a software halt Instruction is exe- 
Uslng cuted, the CPU enters the Halt state by 
Interrupts executing No-OPs (NOPs) until an interrupt or 
RESET is received. Each NOP consists of one 
Ml cycle with four T stat es. The CPU samples 
the state of the NMI and INT lines on the 
rising edge of each T4 clock (Figure 7). 



When an interrupt exists on either line, the 
subsequent cycle will be either a memory read 
o pera tion (NMI) or an interrupt acknowledge 
(INT). The timing in Figure 7 shows a mask- 
able interrupt causing the CPU to exit the 
Halt state. 
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Figure 7. Exit Halt State with Maskable Interrupt 



INTERRUPT Understanding maskable interrupt processing 
PROCESSING requires a familiarity with how the Z80 
BY Z80 peripherals respond to the CPU interrupt 
PERIPHERALS sequence. The Z80 family products were 

designed around the daisy-chain interrupt 
configuration, which utilizes minimal 
external hardware (compared to para I lei con- 
tention resolution interrupt priority net- 
works). Many devices handle interrupts via a 
handshake arrangement, e.g. the use of 
interrupt request and interrupt acknowledge 
signals. This Is the most straightforward 
and probably the fastest method of Implement- 
ing prioritization using more than one 
interrupting device. However, this method 
requires a separate interrupt request signal 
for each peripheral device and either a 
separate acknowledge signal for each device 
or a software acknowledge. Extra hardware Is 
needed to provide contention resolution 
should two or more devices request an Inter- 
rupt simultaneously. With the Z80 product 
family, however, such extra hardware Is 
unnecessary and the software does not need to 
remove the Interrupt request from the periph- 
eral device. This is made possible through 
use of the daisy-chain priority network, 
which can best be visualized as a type of 
bucket brigade. 

The Z80 peripheral products implement this 
daisy chain with just three extra signal 
lines on each chip: Interrupt enable Input 



(IEI), Interrupt en able output (IEO), and 
Interrupt request (INT). The Interrupt 
request line Is an o pen-drain circuit that is 
OR wired to the INT pins of the other devices 
in the chain and connected to the INT pin on 
the Z80 CPU. This line provides the inter- 
rupt request to the CPU. 



The IEI and IEO lines provide the means for 
establishing priority among several request- 
ing devices. The priority of a device is 
determined by its position in the chain. The 
IEI pin of the highest priority device In the 
chain Is connected to +5 volts. The IEO pin 
of the same device Is connected to the IEI 
pin of the next highest priority device. The 
IEO pin of that device goes to the IEI pin of 
the next lower device, as shown In Figure 8, 
and so on to the last device In the chain, 
where the IEO pin is left open. When a 
devi ce h as an Interrupt pending, It activates 
its INT output which requests service from 
the CPU and brings its IEO pin Low, thereby 
preventing the lower devices in the chain 
from responding to further interrupt opera- 
tions. When the CPU acknowledges the inter- 
rupt, the requesting device removes Its 
interrupt request (TNT) signal. After the 
interrupt processing Is completed, the 
peripheral will reset Itself with an RETI 
Instruction, which will bring IEO High and 
restore the chain to Its quiescent state. 



611-1809-0003 



2-27 



12/1/80 



+ 5V 



+ 5V 



+ 5V 



+ 5V 



+ 5V 



+ 5V 



+ 5V 




+ 5V 



+ 5V 



+ 5V 



NOTES. 

1. Device 3 has an interrupt pending (IP set), which causes its 
IEO pin to go low preventing device 4 from interrupting. 

2 CPU acknowledges the interrupt and device 3 has its inter- 
rupt under service (IUS set). The device's IP is then reset 

3 Device 1 requests service, suspending device 3 processing. 
(Assuming interrupts were reenabled.) 

4. Device 1 has its interrupt under service. 

5 CPU completes processing for device 1 and returns to device 3 

service routine 
6. CPU completes processing for device 3 and the daisy chain 

returns to quiescent state. 



Figure 8. Z80 Peripheral Device Interrupt Processing Sequence 
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Interrupt The Z80 peripherals are acknowledged by the 
Acknowledge CPU and then serviced by an appropriate 
Operation Interrupt service routine. The acknowledge 

to the peripherals Is accompl I shed by the C PU 
executing a special Ml cycl e In whjch IORQ 
goes active Instead of MREQ and RD. Whenever 
MT" goes active, all peripheral devices are 
Inhibited from changing their Interrupt 
status. This allows time for IEO to propa- 
gate th rough the other devices In the cha in 
before IORQ goes active. As soon as IORQ and 
*FTT go active, the peripheral device that has 
Its I El High and an Interrupt pending gates 
an 8-blt vector onto the data bus. (See 
Figure 9 for timing details.) This 8-blt 
vector, which was programmed Into the 
peripheral device, Is combined with the con- 
tents of the I register In the CPU to form a 
16-blt addre ss value. During the time that 
M1 and IORQ are active, the requesting device 
removes the INT signal (since the CPU has 



acknowledged It) and waits for a return 
operation. If the peripheral device has Its 
I El pin High and has had an interrupt ack- 
nowledged, then It completes the Interrupt 
cycle and releases IEO (when It sees an RETI 
Instruction IED-4D sequence! on the data 
bus). This restores the chain to Its normal 
state so that lower priority Interrupts can 
occur. 

The Z80 peripherals monitor MT and RD" f or the 
Interrupt acknowledge cycle. Since RD" goes 
active before IORQ, the peripheral devices 
assume an Interrupt acknowledge cycle If Ml 
Is active and RD Is not. This reduces the 
time required for the Internal device logic 
to respond to IORQ when It goes active. 

Thus, a very powerful Interrupt-drlven system 
can be Implemented with minimal hardware, 
simple software, and high efficiency using 
the Z80 family components. 
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Figure 9. Peripheral Interrupt Acknowledge 



Return from When the CPU executes an RETI Instruction, 
Interrupt the device with an Interrupt under service 
Operation resets Its Interrupt condition, provided that 
IEI Is High. All Z80 peripheral products 
sample the data bus for this Instruction when 
Ml goes active along with RD. 

The RETI Instruction decode by the peripheral 
device has certain characteristics that the 
designer should be aware of. Since a pe rlph - 
eral can request an Interrupt (activate INT 
and bring IEO Low) at any time, It Is pos- 
sible for a device whose Interrupt Is cur- 
rently under service to have Its IEI pin Low. 
This Is undesirable, since such a condition 
prevents the peripheral from resetting I US 
properly. To overcome this problem, all Z80 
family peripherals bring IEO High momentarily 



when the ED Is seen during the ED-4D 
Instruction fetch. The device whose Inter- 
rupt Is under service does not allow IEO to 
go High, but when It sees IEI High, It will 
reset Itself when the 4D byte Is fetched. 

Figure 10 s hows the relationship of IP and 
IUS to INT, IEI, and IEO. IP Is set by an 
Interrupt condition on the peripheral (such 
as the transmit buffer becoming empty) when- 
ever Interrupts are enable d. However, IP 
being set will only cause INT to go active 
(requesting an Interrupt) If IUS Is not set 
and IEI Is High. IP Is not necessarily 
cleared by the Interrupt acknowledge cycle. 
Some specific action must be taken within the 
service routine, such as filling a transmit 
buffer. Under these conditions, IUS becomes 
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set and disables IEO to prevent lower |p 

priority devices in the chain from responding 

to an interrupt cycle. I US Is cleared when and 

I El is High and the peripheral decodes a 

valid "ED-4D" instruction. Thus, 



INTACK * INT COND 



IEO = IEI * IUS * (IP + "ED") 
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a) State Diagram of Z80 Peripherals During Interrupt Cycle 



IEI IP IUS IEO 



IEI IP IUS IEO 



b) Truth Table of Daisy Cham During Idle 
or Interrupt Acknowlege Condition. 



c) Truth Table of Daisy Chain During 
"ED" Decode of Opcode Fetch 
Note That IP Is Not Part of IEO Condition. 



Figure 10. Z80 Peripheral Interrupt States 



DAISY CHAIN There are several aspects of the Z80 family 
DESIGN daisy chain implementation that deserve 

CONSIDERATIONS further attention. 

First, since the peripheral devices must be 
able to monitor the data bus in order to 
decode the RET I instruction properly, a means 
of allowing them access to the data bus must 
be provided if buffers are used. This can be 
done by simply enabling the buffers from the 
data bus to the peripheral for all conditions 
except I/O read and interrupt acknowledge. 
Since the peripheral must assert an 8-bit 



vector during interrupt acknowledge, the 
buffers must also accommodate this. 
Second, because the peripheral devices have a 
finite time during which IEI and IEO can 
stabilize within, the propagation delay of 
the devices must be taken into consideration. 
Since a device can change its interrupt 
status until reaching the active edge of W\ 
during interrupt ackn owledge, the time from 
this edge until I0RQ becomes active is the 
time in which the daisy chain must stabilize. 
Figure 11 shows the timing relationships 
involved in this process. 
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RIPPLE TIME FOR DAISY CHAIN = 
T d M1(IEO) + TdlEI(IEOF) * [N-2] +T s IEI(IO) + TTL BUFFER DELAY (IF ANY) 
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DEVICES, TO WORST CASE 
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Figure 11. Interrupt Acknowledge Peripheral Propagation Delay 
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The Z80 CPU au tomatic al ly inserts two wait 
states during INTACK, allowing a worst-case 
time for a chain of four devices to become 
settled (when using Z80A CPU and peripherals 
at 4MHz). If more devices are In the chain, 
some other means of stabilizing the chain 
must be provided. This can be done either b y 
adding additional wait states to the INTACK 
cycle or by providing logic to the periph- 
erals that a I lows faster propagation time 
down the chain. Figure 12 shows circuitry 
that provides both additional wait states and 
an Interrupt look-ahead circuit when more 
than four peripheral devices are connected to 
the daisy chain. 



When adding wait states to the Z80 CPU Inter- 
rupt acknowledge cycle, care must be taken to 
Insure that IORQ goes active at the prop er 
time. Normally, the CPU activates IORQ on 
the falling edge of the clock during the 
first wait cycle. If external logic Is used 
to Insert additional wait states, these are 
appended to the two wait states alre ady 
generated by the CPU. Because IORQ goes 
active during the first wait state and the 
peripherals asse rt t heir vectors when IORQ 
becomes active, IORQ must be Inhibited until 
the daisy chain becomes stable. This can be 
done simply by addin g a few gates to the wait 
logic (Figure 13). TOR^' is the delayed "IORQ 
that activates the peripheral devices. 




IORQ (to peripheral) 



2 WAIT STATES ADDED 




Figure 12A. Daisy Chain Look-Ahead Logic for More Than Four Peripheral Devices 
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The propagation delay through the peripheral 
devices applies during the return from 
interrupt condition, also. Worst-case 
timing involves the lowest priority device 
that has an interrupt under service and the 
highest priority device that has an inter- 
rupt pending. When the ED part of the RETI 
opcode is fetched, the peripheral devices 
must decode it, and the highest priority 
device must bring its I EO pin High, This 
IEO high signal must then propagate through 
the chain down to the lowest priority device 



before the 4D part of RETI is decoded. 
Figure 14 shows the timing relationships 
involved. This timing is not as critical as 
the interrupt acknowledge timing at 4 MHz, 
but should be consi dered if wait states are 
being added to the INTACK cycle. 
If using nested interrupts with a large daisy 
chain, the programmer should be careful not 
to place the RETI opcodes too close together. 
Since RETI is 14 cycles long, this is 
generally not a problem unless a very long 
chain is used. 
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Figure 13. Wait State Logic for Interrupt Acknowledge Cycle. 

Counter Preset Value Should Be 5-n, Where n = # Wait 
State Added 




NOTES: 

1. Setup time for IEI to "4D" decode * 200ns (4 MHz) 

2 Must look at IEI during ED-4D because nested interrupts 

allow more than 1 IUS latch to be set at one time. 
3. Delay time from ED decode with IP set to IEO high 

* 300ns (typ) 400ns (max) @2.5 MHz. This in in addition to 

ripple time for other devices in chain. 

T r :> T d ED(IEO r ) + T d IEI(lEO r ) * [N-2] + T S IEI(4D) 



for N-2 devices 
T d ED(IEO r ) = Delay time from "ED" decode to IEO rise. 
T d IEI(IEO r ) = Delay time from IEI high to IEO rise. 
T S IEI(4D) = Setup time tor IEI during "4D" decode. 
(For last device in chain.) 
Figure 14. Daisy Chain Interrupt Timing (RETI Condition) 
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SPECIAL CASES Interfacing Zilog 8500 series peripheral 
OF INTERRUPTS products (CIO, FIO, SCC, etc.) to the Z80 CPU 
Is a little different from Interfacing the 
Z80 peripherals to the CPU. 
The primary difference between the Z80-type 
peripherals and the 8500-type peripherals Is 
In the interrupt acknowledge circuitry. 
Functional ly, they are the same, as can be 
seen In the timing diagrams of Figure 15. 
However, the 8500 peripherals do not sample 
Ml, RD, and I0RQ for the in terrupt acknowl- 
edge, but have an explicit INTACK pin to 
signal the Interrupt acknowledge. Also, 
since the 8500 peripherals have a software 
reset for the interrupt under service flip- 
flop, these devices do not require a special 
return opcode to do that operation. The user 
need only be concerned with the Interrupt 



acknowledge timing when using the 8500-type 
peripherals. 

Figure 16 shows a circuit that provides wait 
states for the Z80 CPU Interrupt acknowledge 
cycle In addition to I NTACK generation. The 
I0RQ ! circuitry can be omitted If no Z80 
family peripheral devices are used. 

In each c ase, th e 8500 peripheral component 
requires I NTACK and RD" to be active In order 
for the Interrupt vector to be made available 
to the CPU. The logic shown provides for 
this. 

This circuitry also permits extended Inter- 
rupt acknowledge times to allow for the daisy 
chain propagation delay and the vector 
response delay, so that larger chains can be 
implemented. 




Figure 15. Timing for 8500 Peripherals During Interrupt Acknowledge. 

LS11 





NOTE- 

1. RD and WR should only be 
connected to 8500 peripherals 
and not to £80 peripherals. 



Figure 16. Interface Logic For Connecting 8500 Series Peripherals To Z80 System 
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Interrupt A RESET to the Z80 CPU does several things as execute an El instruction, just as if a Dl 

During RESET far as interrupts are concerned. The I instruction were executed. If an NMI occurs 

register, which contains the upper eight bits during the RESET operation, the CPU executes 

of the 16-bit interrupt address value, is one instruction after the RESET condition and 

reset to 0, and the interrupt mode is set to before acknowledging the NMI. Processing 

Mode 0. Maskable interrupts are disabled then continues as usual, 
until the programmer instructs the CPU to 
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INTRODUCTION In certain applications, serial data com- 
munications can be handled more efficiently 
by using a DMA device In conjunction with a 
serial controller. This application brief 
describes the use of the Z80A SIO and Z80A 
DMA hardware and software in a Z80-based 
system to transfer data to the SIO via the 
DMA. 

Transfers through a serial data medium are 
usually done with a serial controller device, 
often a Universal Synchronous/Asynchronous 
Receiver/ Transmitter (USART), such as the 
Z80 SIO, Additionally, some sort of con- 
trolling device is required to manipulate the 
data on a character-by-character basis, 
(usually a CPU), Transferring characters can 



be accomplished either by polling the USART, 
which forces the CPU to take time away from 
other activities, or by Initiating an Inter- 
rupt mechanism, which requires CPU time only 
If there Is data to be moved. However, when 
large blocks of data need to be moved, even 
the interrupt mechanism becomes awkward. In 
these cases, a Direct Memory Access (DMA) 
device Is especially valuable. 

With DMA transfer, data Is moved directly 
between memory and I/O (or additional memory) 
without CPU Intervention, Once initiated by 
the CPU, DMA operation continues transpar- 
ently to CPU operation until completed. Then 
the DMA device can either Interrupt the CPU 
or restart Its cycle using the previously 
programmed parameters. 



HARDWARE The hardware used in the example for this 

DESCRIPTION brief consists of a Z80A CPU, a Z80A DMA 

controller, a Z80A SIO/2, some RAM and ROM, 
and some support circuitry (Figure 1), 

The Z80A DMA contains a 16-bit address bus, 
an 8-bit data bus, and 13 control lines for 
external interfacing. The Z80 DMA can gen- 
erate independent addresses for Port A and 
Port B, Each address can be variable or 
fixed. Variable addresses can be programmed 
to either increment or decrement from the 
programmed starting addresses, whereas fixed 
addressing eliminates the need for separate 
enabling lines for I/O ports. 

Readable registers contain the current 
address of each port and a count of the 
number of bytes searched and/or transferred. 
Additional registers allow the DMA to perform 
bit-maskable data comparisons on the data 
that Is being searched and/or transferred. 
The DMA has 21 writeable control registers 
and seven readable status registers, which 
together provide a high degree of program- 
mabi I ity. 



The DMA function described is for a simple 
test operation using memory-to- I/O transfer 
with no search options. The DMA Is Initial- 



ized to transfer data from a pattern in 
memory to the SIO when the SIO requests a 
byte via the MIT/RDY signal line. The SIO 
then sends the byte to a terminal, which 
displays It for visual Inspection. After a 
block of bytes has been sent, the DMA 
restarts itself (Auto Restart mode) and the 
process repeats continuously. Since the data 
pattern in memory consists of dlsplayable 
ASCII characters, data is easily verified by 
observing the characters displayed on the 
terminal • 

One feature of the Z80 DMA is the ease with 
which it interfaces with the Z80 CPU. The 
DMA is designed to connect directly to the 
CPU, as illustrated in Figure 2. The 16 
address lines, eight data lines, and seven 
control lines are connected directly to the 
corresponding lines on the Z80 CPU. These 
signals are then buffered by the 74LS241S and 
distributed to the rest of the system. The 
data bus is buffered by the 74LS245 bidirec- 
tional octal buffer. Othe r co nnections to 
the DMA include clock, CE/WAIT, INT, RDY and 
IEI. 

The clock input to the DMA is sensitive to 
both level and rise and fa I I times. The 
voltage should be no greater than +0.45V for 
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high level. Additionally, the rise and fall 
times for the waveform should be no greater 
than 30ns, according to the device specifi- 



cations, A clock driver device is used to 
deliver the proper voltage levels and rise/ 
fal I times. 



OSCILLATOR K 



Z80 
CPU 



Z80 
DMA 



DATA 
BUS 



RDY 
SIO/2 



BIDIRECTIONAL 
BUFFER 



Figure 1. Block Diagram of a Z80 System with DMA and SIO. 




Figure 2. Schematic of CPU and DMA Interface 
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The CE/WAIT input to the DMA serves a dual 
purpose. When the DMA Is idle [Bus Ack nowl- 
edge Input (BAD inactive], the CE/WAIT input 
is used to select the DMA during a CPU access 
cycle, a I lowing the DMA to be treated as a 
peripheral device by the CPU. However, when 
the DMA takes control of the system b us, the 

CE/WAIT input can be programmed as a WAIT 

control line for the DMA, similar to the WAIT 
input on the Z80 CPU, Figure 3 sh ows the 
gating that determines the CE/WAIT function. 



trolled by the CPU circuitry. However, in 
larger systems, any buffers near the SIO need 
to be considered. 

In addition, the system must supply some form 
of bit rate clock to the SIO for data com- 
munications. This is accomplished either by 
using an external clock source or by gener- 
ating the clock with a device such as the CTC 
or CIO. Here the clock is supplied at a IX 
rate for asynchronous communications from an 
external device such as a modem. 




■■ (DMA SEL •_BAI) + (WAIT • BAI) 
Bus Acknowledge Input (BAI) is active Low during the DMA cycle 

Figure 3. CE/WAIT Control Logic. 

With the SIO, the hardware interface Is 
slightly more complex than the DMA hardware 
Interface. The interface to the Z80 CPU is 
fairly straightforward, since the SIO Is 
accessed as an I/O peripheral device. Still, 
the clock input has the same requirements as 
the DMA; so in order to provide this signal, 
some sort of clock driver is needed. In 
addition, if the SIO is used in an interrupt 
environment where its internally generated 
vector is placed onto the data bus, the data 
bus buffers must allow the interrupt vector 
to be presented to the CPU during the Inter- 
rupt acknowledge cycle. Since the data bus 
is buffered at the CPU, this Is not a problem 
with the example given here; the bus is con- 



The WAIT/RDY pin on the SIO is connected to 
the RDY input on the DMA. This provides 
character transfer control between the SIO 
and DMA. In this appl I ca t ion , the ready 
function is used and the WAIT/RDY pin is 
wired directly to the RDY Input on the DMA 
with a pu I t up resistor. A low level Initiates 
a DMA character transfer from mem ory to the 
SIO. The SIO drives the WAIT/RDY line High 
or Low so that pull up Is not strictly 
requ i red . However, upon reset, the SIO 
WAIT/RDY pin floats until the ready function 
is programmed in the SIO. Figure 4 shows the 
Z80 CPU-SIO interface. 

Since the SIO has only one WA I T/RDY pin per 
channel, it can be used with the DMA only 
during transmit or receive but not both 
simultaneously. Therefore, characters re- 
ceived by the SIO are transferred via inter- 
rupts with the CPU intervening . The 
interrupt system also handles errors detected 
either during reception or when the SIO 
notices an external or status change. 
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Figure 4. Z80 SIO Interface 
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PROGRAMMING Before any action can occur, Initialization 
must be performed on the Z80 CPU, the DMA, 
and the SIO devices. Since interrupts are 
used in processing special SIO conditions, 
the Z80 CPU must be initialized for the 
proper interrupt mode. In the example, the 
CPU is set to Interrupt Mode 2 using the IM 
instruction. The upper eight bits of the 
interrupt vector are loaded into the I 
register via the A register in the CPU. The 
Stack Pointer (SP) register must be loaded by 
the program upon reset, because it has an 
undefined value. The SP register is used 
when processing interrupts and when the Cal I 
instruction is executed during initializa- 
tion. The appendix contains a source listing 
for a DMA test program using the SIO. 
The DMA is initialized for memory-to- I/O, 
byte-at-a-time transfer with the search 
option disabled and operates continuously 
until stopped by a command from the CPU. The 
program uses Port A of the DMA for the memory 
source address (SRC) and Port B for the 
destination address (DST) and utilizes the 
auto restart option on the DMA so that data 
can be sent to the terminal as a stream of 
characters. Since Port B is a fixed des- 
tination address, it must be declared as the 
source when the DMA is given the Load command 
(WR6, CFH), as stated in the programming 
section of the DMA Technical Manual (document 
number 00-2013-A). Table 1 shows the ini- 
tial ization sequence for the example des- 
cribed here. 

The SIO initialization sequence is straight- 
forward. The example uses channel A in 
Asynchronous Communication mode with the DMA 
providing data characters to the SIO on a 
transmit buffer empty condition. The ter- 
minal requires async format, two stop bits, 
and even parity. An external 1X clock is 
used with the SIO for the bit rate clock. The 
lower eight bits of the SIO interrupt vector 
are loaded into WR2 through channel B, and 
the Status Affects Vector (SAV) bit in WR1 is 
also set. SAV provides eight separate in- 
terrupt vectors (four for each channel ), 
allowing easy program operation. Table 2 
shows the programming sequence and mode of 
the SIO for DMA operation. Note that when 
DMA transfers are used to move data, the 
transmit buffer empty interrupt should not be 
enabled (WR1, bit 1=0). 

A data test pattern is generated in the 
memory buffer area used for transmission to 
the SIO so that intelligible information can 
be sent to the terminal for easy verifica- 
tion. This is done by a short routine that- 
fills the memory block with an incremental 
pattern of ASCI I characters in the range of 
from 20H to 7FH and appends a carriage return 
and a linefeed to the data block. Figure 5 
contains a listing of the routine involved. 
The block length programmed into the DMA is 
one less than the actual block length trans- 
ferred due to the counter characteristics of 
the Z80 DMA. 



Table 1. DMA Initialization Sequence 

1. Disable DMA 

2. Issue six reset commands 

(insures a reset if DMA in undefined 
state) 

3. WRO - Port A (source) characteristics 

4. Port A start address - low byte 

5. Port A start address - high byte 

6. Port A block length - low byte 

7. Port A block length - high byte 

8. WR1 - Port A increment address 

9. WR2 - Port B is fixed address, I/O 

10. WR4 - Byte mode, Port B address (low 
byte) follows 

11. Port B (destination) address 

12. WR5 - Auto Restart mode, CE/WAIT is 
mu Itip lexed 

13. Insure Port A is standard timing 

14. Insure Port B is standard timing 

15. Load Port B 

16. WRO - Port A is source, Port B is des- 
tination 

17. Load Port A 

Table 2. SIO Initialization Sequence 
Channel A 

1. Channel Reset 

2. WR1 - WATt/RDY enable for TX, ready 
function, RX interrupt on all characters; 
parity affects vector 

3. WR4 - X1 clock, two stop bits, even 
parity 

4. WR5 - DTR, RTS active, TX seven bits, 
enable TX 

5. WR3 - RX seven bits 

Channel B 

1. Channel Reset 

2. WR1 - status affects vector 

3. WR2 - lower eight bits of vector 
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Once the CPU, DMA, and SIO are set up, the 
program enables the DMA device (WR6, 87H) and 
the data tr ansf er process begins. The SIO 
brings the WA I T/RDY output active as soon as 
the SIO has been initialized so that char- 
acters can be transmitted immediately. The 
user must Insure that the DMA and data block 
have been set up properly before any data 
transfer actual ly occurs, DMA data transfer 
is different from the interrupt data transfer 
of the SIO, because with interrupts the SIO 
does not request data until it is activated 
by having a character sent to it. 



Once operation of the DMA and SIO has begun, 
data transfers occur without CPU intervention 
unless the SIO encounters an error condition. 
An error causes the SIO to interrupt the 
CPU, thereby intervening in CPU processing. 
In this event, the CPU is interrupted by the 
device detecting the error and the DMA pro- 
cessing is terminated by the CPU. This 
termination Is achieved by writing a command 
word to the DMA. The DMA remains disabled 
until given a command that enables It. 



LOOP: 



LD 


HL, SRC 


LD 


BC, BLKSIZ-2 


LD 


D, 20H 


LD 


(HL), D 


INC 


D 


LD 


A,D 


AND 


7FH 


OR 


20H 


LD 


D,A 


INC 


HL 


DEC 


BC 


LD 


A,B 


OR 


C 


JR 


NZ, LOOP 


LD 


(HL), 13 


INC 


HL 


LD 


(HL), 10 



;#HL = start address 
;$BC = length 
;%D - data byte 

; store character 

; increment character code 

;mask upper bit 

;keep dlsplayable character 
;save In %D 
;Bump memory ptr. 
;Bump byte count 
;see if through 



;no-loop 
;CR 



;LF 



Figure 5. Data Test Pattern Generator 



Routine Listing. 



CONCLUSION This example shows only one aspect of using 

the DMA with the SIO. Use of the DMA with 
the SIO during receive deserves special con- 
sideration. Since the DMA operates without 
CPU processing, data received by the SIO does 
not normally indicate when the end of a 
message occurs. One solution to this problem 
is to send fixed- length data blocks so that 
the CPU can be Interrupted when the DMA 
reaches terminal count. This is done by 
programming a fixed-length block count into 
the DMA and enabling it to interrupt the CPU 
upon End-Of-Block (EOB). As an alternative 
to the terminal count Interrupt, the SIO can 
be programmed to Interrupt the CPU when the 
closing flag is detected In SDLC mode. This 
a I lows the CPU to detect the end of a message 
using the SIO Instead of the DMA. 

Another method of detecting the end of a 
message is to dedicate a special EOB char- 
acter used to terminate al I message blocks. 



The DMA can then be programmed to search for 
this character during data transfers and to 
Interrupt the CPU when the character Is 
detected. This method allows for variable- 
length message blocks, up to the maximum byte 
count the DMA will accommodate. The disad- 
vantage with this method is that the user 
must dedicate one character as the special 
EOB character. 



The unique features of the DMA and SIO com- 
bine to form a powerful and flexible data 
communication mechanism. Due to the de- 
signed-in compatibility of the SIO and DMA, 
interfacing with both in hardware and soft- 
ware becomes a simplified task. Programming 
is easy because very little CPU intervention 
is necessary after initialization. Thus, the 
user is afforded a powerful tool for imple- 
menting an efficient, cost-effective data 
processing system. 



APPENDIX Following is a printout of the DMA/SIO test 

program. This program uses the DMA to 
transfer data from a pattern in memory to the 
SIO, which then sends the data, in async 
format at 9600 baud, to a terminal for dis- 
play. The process continues until it is 
external ly interrupted, such as by a reset. 

Interrupts are used to process error con- 



ditions or to receive characters. However, no 
code is shown that handles the characters 
once they are received. Error conditions are 
reset by the interrupt service routine, 
although nothing is shown for these condi- 
tions either. The user normal ly sets a 
condition flag after resetting the error 
condition, so that the driver program can 
determine the appropriate course of action. 
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LOG 



DMAS 10 
OBJ CODE M STMT SOURCE STATEMENT 



ASM 5. 9 



1 


; 


DMA/SIO 


TEST PR( 


3QRAM 




2 












3 
4 
5 


i 


BY M. PITCHER - 


10/10/80 


i 


GENERATES BLOCK 


OF DATA 


IN RAM, 


6 


i 


THEN OUTPUTS TO 


SIO VIA 


DMA* 


7 

8 
9 


'' 


THEN CONTINUES 1 


-OREVER. 




RAM: 


EQU 


2000H 




;RAM START ADDR 


10 


RAMSIZ: EQU 


1000H 




;RAM SIZE 


11 


SIODA 


EQU 







i SIO CH. A DATA PORT 


12 


SIOCA 


EQU 


SIODA+1 




iSIO CH. A CTRL PORT 


13 


SIQDB 


EQU 


SIODA+2 




i SIO CH. B DATA PORT 


14 


SIOCB 


EQU 


SIODB+1 




iSIO CH. B CTRL PORT 


15 


DMA: 


EQU 


OFOH 




i DMA PORT ADDR 


16 


DST: 


EQU 


SIODA 




i DESTINATION ADDR 


17 


BLKSIZ: EQU 


64 




i XFER BLK SIZE 


18 


DMABLK: EQU 


BLKSIZ- 


1 


i DMA BLOCK SIZE VALUE 


19 












20 












21 


, 


START DMA AFTER 


INITIALIZATION (WR6, 87H ) 


22 


, 


DMA PARAMETERS 






23 












24 


DMAWRO: EQU 









25 




XFER: 


EQU 


1 




26 




SRCH: 


EQU 


2 




27 




XFRSCH: 


EQU 


3 




28 




A B: 


EQU 


4 




29 




ALSTA. 


EQU 


8 




30 




AHSTA: 


EQU 


10H 




31 




ALBLEN: 


EQU 


20H 




32 




AHBLEN: 


EQU 


40H 




33 












34 


DMAWR1: EQU 


4 






35 




AIO: 


EQU 


8 




36 




AINCR: 


EQU 


10H 




37 




ADECR: 


EQU 







38 




AFIXED: 


EQU 


20H 




39 




AVTIM: 


EQU 


40H 




40 












41 


DMAWR 


2: EQU 









42 




BIO: 


EQU 


8 




43 




BINCR: 


EQU 


10H 




44 




BDECR: 


EQU 







45 




BFIXED. 


EQU 


20H 




46 




BVTIM: 


EQU 


40H 




47 












48 


DMAWR3: EQU 


80H 






49 




DMAEN: 


EQU 


40H 




50 




INTEN: 


EQU 


20H 




51 




MCHBYT- 


EQU 


10H 




52 




MSKBYT 


EQU 


8 




53 




SOMCH 


EQU 


4 




54 












55 


DMAWR4: EQU 


81H 






56 




BYTE. 


EQU 







57 




CONT: 


EQU 


20H 




58 




BURST: 


EQU 


40H 




59 




ICB- 


EQU 


10H 




60 






INTRDY: 


EQU 


40H 


61 






DM ASA V: 


EQU 


20H 


62 






IV: 


EQU 


10H 


63 






PCB: 


EQU 


8 


64 






PULSE: 


EQU 


4 


65 






INTEOB: 


EQU 


2 


66 






INTMCH: 


EQU 


1 


67 












68 




BHSTA. 


EQU 


8 




69 




BLSTA: 


EQU 


4 




70 












71 


DMAWR 5: EQU 


82H 
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DMAS 10 
OBJ CODE M STMT SOURCE STATEMENT 



ASM 5 9 



72 




AUTORS- 


EQU 


20H 


73 




CEWAIT 


EQU 


10H 


74 




RDYHI: 


EQU 


8 


75 










76 




SETUP FOR ASYNC 


FORMAT AS FOLLOWS 


77 






9600 BAUD 


78 






2 STOP 


BITS 


79 






7 BIT CHARACTERS 


80 






EVEN PARITY 


81 










82 




PROGRAM 


ASSUMES 


DMA XFER OF TX DAT 


83 




THERE IS NO RECV DATA XFER 


84 




STATUS 


IS REFLECTED IN "SIOFLG" LO 


85 




EXTERNAL TX AND 


RX CLOCK ASSUMED 


86 










87 




SIOFLG 


-XXI 


1 X X 1 1 


88 






/ 


i i > 


89 






ERROR ASLEEP ERROR ASLEEP 


90 






CHANNEL B CHANNEL A 


91 










92 


SIOWRO: 


EQU 







93 




CHRES: 


EQU 


18H 


94 




ESCRES: 


EQU 


10H 


95 




TBERES: 


EQU 


28H 


96 




SRCRES- 


EQU 


30H 


97 




RCRCRE: 


EQU 


40H 


98 




TCRCRE: 


EQU 


80H 


99 




EOMRES: 


EQU 


OCOH 


100 










101 


SI0WR1: 


EQU 


1 




102 




WREN: 


EQU 


80H 


103 




RDY: 


EQU 


40H 


104 




WRONR- 


EQU 


20H 


105 




RXIFC: 


EQU 


8 


106 




RXIAP- 


EQU 


10H 


107 




RXIA. 


EQU 


18H 


108 




SIOSAV: 


EQU 


4 i CH. B ONLY 


109 




TXI: 


EQU 


2 


110 




EXTI: 


EQU 


1 


111 










112 


SI0WR2- 


EQU 


2 


i CH. B ONLY 


113 










114 


SI0WR3. 


EQU 


3 




115 




RX8. 


EQU 


OCOH 


116 




RX6: 


EQU 


80H 


117 




RX7: 


EQU 


40H 


118 




RX5: 


EQU 





119 




AUTOEN: 


EQU 


20H 


120 




HUNT: 


EQU 


10H 


121 




RXCRC: 


EQU 


8 


122 




ADSRCH: 


EQU 


4 


123 




SYNINH: 


EQU 


2 


124 

1 ^>*s» 




RXEN: 


EQU 


1 


126 


SI0WR4: 


EQU 


4 




127 




X64: 


EQU 


OCOH 


128 




X32: 


EQU 


80H 


129 




X16: 


EQU 


40H 


130 




XI: 


EQU 





131 




EXTSYN: 


EQU 


30H 


132 




SDLC: 


EQU 


20H 


133 




SYN16: 


EQU 


10H 


134 




SYN8: 


EQU 





135 




ST0P2: 


EQU 


OCH 


136 




STOP 15: 


EQU 


8 


137 




STOP 1 : 


EQU 


4 


138 




SYNCEN: 


EQU 





139 




EVEN: 


EQU 


2 


140 




PARITY: 


EQU 


1 


141 










142 


SI0WR5: 


EQU 


5 
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LOC 



DMAS 10 
OBJ CODE M STMT SOURCE STATEMENT 



ASM 5. 9 









143 




DTR 


EQU 


80H 










144 




TX8 


EQU 


60H 










145 




TX6 


EQU 


40H 










146 




TX7 


EQU 


20H 










147 




TX5 


EQU 













148 




BREAK: EQU 


10H 










149 




TXEN: EQU 


8 










150 




CRC16: EQU 


4 










151 




RTS 


EQU 


2 










152 




TXCRC: EQU 


1 










153 


















154 


SI0WR6: 


EQU 


6 












155 


















156 


SI0WR7: 


EQU 


7 












157 


*EJ 
















158 


















159 


; ; 


*#* 


MAIN PROGRAM *** 










160 














OOOO 




161 




ORG 











OOOO 


C32000 


162 
163 




JP 


BEGIN 








0010 




164 




ORG 


*. AND. OFFFOH. 


OR. 10H 








165 


INTVEC: 
















166 


SIOVEC: 












0010 


6400 


167 




DEFW CHBTBE 








0012 


7600 


168 




DEFW CHBESC 








0014 


7000 


169 




DEFW CHBRCA 








0016 


8A00 


170 




DEFW CHBSRC 








0018 


9E00 


171 




DEFW CHATBE 








001 A 


B000 


172 




DEFW CHAESC 








001C 


AAOO 


173 




DEFW CHARCA 








001E 


C400 


174 




DEFW CHASRC 












175 


















176 


BEGIN: 












0020 


318120 


177 




LD 


SP,STAK 




i INIT SP 




0023 


ED5E 


178 




IM 


2 




i INTERRUPT MODE 2 




0025 


3E00 


179 




LD 


A, INTVEC /256 






0027 


ED47 


180 




LD 


I, A 








0029 


CD4D00 


181 




CALL INIT 




; INIT DMA, SIO 




002C 


210120 


182 




LD 


HL-SRC 




: GENERATE DATA PATTERN 




002F 


013E00 


183 




LD 


BCBLKSIZ-2 






0032 


1620 


184 
185 


LOOP: 


LD 


D, 20H 








0034 


72 


186 




LD 


(HL),D 








0035 


14 


187 




INC 


D 








0036 


7A 


188 




LD 


A, D 








0037 


E67F 


189 




AND 


7FH 








0039 


F620 


190 




OR 


20H 








003B 


57 


191 




LD 


D, A 








003C 


23 


192 




INC 


HL 








nrsorv 


OB 


193 




DEC 


BC 








003E 


78 


194 




LD 


A, B 








003F 


Bl 


195 




OR 


C 








0040 


20F2 


196 




JR 


NZ,LOOP 








0042 


360D 


197 




LD 


(HL), 13 




i CR 




0044 


23 


198 




INC 


HL 








0045 


360A 


199 




LD 


(HL), 10 




, LF 




0047 


3E87 


200 




LD 


A, 87H 




; ENABLE DMA 




0049 


D3F0 


201 
202 




OUT 


(DMA), A 








004B 


18FE 


203 
204 
205 
206 


INIT: 
DMAINI: 


JR 


* 




i LOOP FOREVER 




004D 


OEFO 


207 




LD 


C, DMA 




, INIT DMA 




004F 


21EF00 


208 




LD 


HL, DMATAB 






0052 


0616 


209 




LD 


B, DMAEND-DMATAB 




0054 


EDB3 


210 




OTIR 












211 


SIOINI: 












0056 


210501 


212 




LD 


HL/SIOTA 


, INIT SIO CH A 




0059 


0E01 


213 




LD 


C, SIOCA 








005B 


060A 


214 




LD 


B, SIOEA- 


-SIOTA 
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LOC 



DMAS 10 
OBJ CODE M STMT SOURCE STATEMENT 



ASM 5. 9 



005D 


EDB3 


005F 


AF 


0060 


320020 


0063 


C9 



0064 


CDD800 


0067 


3E00 


0069 


D303 


006B 


3E28 


006D 


D303 


006F 


C9 


0070 


CDD800 


0073 


DB02 


0075 


C9 


0076 


CDD800 


0079 


3E00 


007B 


D303 


007D 


3E10 


007F 


D303 


0081 


3A0020 


0084 


CBE7 


0086 


320020 


0089 


C9 


008A 


CDD800 


008D 


3E00 


008F 


D303 


0091 


3E30 


0093 


D303 


0095 


3A0020 


0098 


CBEF 


009A 


320020 


009D 


C9 


009E 


CDD800 


00A1 


3E00 


00A3 


D301 


00 A 5 


3E28 


00A7 


D301 


00A9 


C9 


OOAA 


CDD800 


OOAD 


DBOO 


OOAF 


C9 


OOBO 


CDD800 


00B3 


3E00 


GOB 5 


D301 


00B7 


3E10 


00B9 


D301 


OOBB 


3A0020 


OOBE 


CBC7 


OOCO 


320020 


00C3 


C9 


00C4 


CDD800 


00C7 


3E00 


00C9 


D301 



215 




OTIR 




216 




XOR 


A 


217 




LD 


(SIOFLG), A 


218 




RET 




219 


*EJ 






220 








221 


, 


INTERRUPT SERVICE I 


222 








223 


CHBTBE: 






224 




CALL 


SAVE 


225 




LD 


A, SIOWRO 


226 




OUT 


(SIOCB), A 


227 




LD 


A, TBERES 


228 




OUT 


(SIOCB), A 


229 




RET 




230 








231 


CHBRCA: 






232 




CALL 


SAVE 


233 




IN 


A, (SIODB) 


234 




RET 




235 








236 


CHBESC. 






237 




CALL 


SAVE 


238 




LD 


A, SIOWRO 


239 




OUT 


(SIOCB), A 


240 




LD 


A, ESCRES 


241 




OUT 


(SIOCB), A 


242 




LD 


A, (SIOFLG) 


243 




SET 


4, A 


244 




LD 


(SIOFLG), A 


245 




RET 




246 








247 


CHBSRC: 






248 




CALL 


SAVE 


249 




LD 


A, SIOWRO 


250 




OUT 


(SIOCB), A 


251 




LD 


A, SRCRES 


252 




OUT 


(SIOCB), A 


253 




LD 


A, (SIOFLG) 


254 




SET 


5, A 


255 




LD 


(SIOFLG), A 


256 




RET 




257 








258 


CHATBE: 






259 




CALL 


SAVE 


260 




LD 


A, SIOWRO 


261 




OUT 


(SIOCA), A 


262 




LD 


A, TBERES 


263 




OUT 


(SIOCA), A 


264 




RET 




265 








266 


CHARCA: 






267 




CALL 


SAVE 


268 




IN 


A, (SIODA) 


269 




RET 




270 








271 


CHAESC: 






272 




CALL 


SAVE 


273 




LD 


A, SIOWRO 


274 




OUT 


(SIOCA), A 


275 




LD 


A, ESCRES 


276 




OUT 


(SIOCA), A 


277 




LD 


A, (SIOFLG) 


278 




SET 


0, A 


279 




LD 


(SIOFLG), A 


280 




RET 




281 








282 


CHASRC. 






283 




CALL 


SAVE 


284 




LD 


A, SIOWRO 


285 




OUT 


(SIOCA), A 



(CLEAR SIOFLG 



; CH. B TX BUFFER EMPTY 



;CH. B RX CHAR AVAIL 



, EXTERNAL/STATUS CHG 



iCH. B SPECIAL RX COND 



i CH. A TX BUFFER EMPTY 



, CH. A RX CHAR AVAIL. 



; EXTERNAL/STATUS CHG 



. CH. A SPECIAL RX COND. 
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LOG 



DMAS 10 
OBJ CODE M STMT SOURCE STATEMENT 



ASM 5. 9 



OOCD 


D301 


OOCF 


3A0020 


00D2 


CBCF 


00D4 


320020 


00D7 


C9 



00D8 


E3 


00D9 


D5 


OODA 


C5 


OODB 


F5 


OODC 


DDES 


OODE 


FDE5 


OOEO 


CDEEOO 


00E3 


FDE1 


00E5 


DDE1 


00E7 


Fl 


00E8 


CI 


00E9 


Dl 


OOEA 


El 


OOEB 


FB 


OOEC 


ED4D 



OOEE 



E9 



OOEF 


83 


OOFO 


C3 


00F1 


C3 


00F2 


C3 


00F3 


C3 


00F4 


C3 


OOFS 


C3 


00F6 


79 


00F7 


01 


OOFS 


20 


00F9 


3F 


OOFA 


00 


OOFB 


14 


OOFC 


28 


OOFD 


85 


OOFE 


00 


OOFF 


B2 


OiOO 


C7 


0101 


CB 


0102 


CF 


0103 


05 


0104 


CF 



0105 


00 


0106 


18 


0107 


01 


0108 


DO 


0109 


04 


010A 


OF 


010B 


05 


010C 


AA 


010D 


03 


010E 


40 



286 




LD 


A, SRCRES 






287 




OUT 


(SIOCA), A 






288 




LD 


A, (SIOFLG) 






289 




SET 


1, A 






290 




LD 


(SIOFLG), A 






291 




RET 








292 












293 


, 


MATHEWS 


SAVE REGISTER ROUTINE 




294 












295 


SAVE: 










296 




EX 


( SP ) , HL 


SP * 


HL 


297 




PUSH 


DE 




DE 


298 




PUSH 


BC 




BC 


299 




PUSH 


AF 




AF 


300 




PUSH 


IX 




IX 


301 




PUSH 


IY 




IY 


302 




CALL 


GO 




SAVE PC 


303 




POP 


IY 






304 




POP 


IX 






305 




POP 


AF 






306 




POP 


BC 






307 




POP 


DE 






308 




POP 


HL 






309 




EI 








310 




RET I 








311 












312 


00: 










313 




JP 


(HL) 






314 


*EJ 










315 












316 


; , 


CONSTANTS 






317 












318 


DMATAB : 










319 




DEFB 


83H 


WR6, 


DISABLE DMA 


320 




DEFB 


0C3H 


WR6, 


RESET 


321 




DEFB 


0C3H 


WR6, 


RESET 


322 




DEFB 


0C3H 


WR6, 


RESET 


323 




DEFB 


0C3H 


WR6, 


RESET 


324 




DEFB 


0C3H 


WR6, 


RESET 


325 




DEFB 


0C3H 


WR6, 


RESET 


326 




DEFB 


DMAWRO+XFER+ALST 


*+AHS - 


rA+ALBLEN+AHBLE 


327 




DEFB 


SRC. AND. 255 


PORT 


A ADDR (L) 


328 




DEFB 


SRC/256 


PORT 


A ADDR (H) 


329 




DEFB 


DMABLK. AND. 255 


PORT 


A COUNT (L) 


330 




DEFB 


DMABLK/256 


PORT 


A COUNT (H) 


331 




DEFB 


DMAWR1+AINCR 






332 




DEFB 


DMAWR2+BI0+BFIXE 


D 




333 




DEFB 


DMAWR4+BYTE+BLST 


fl» 




334 




DEFB 


DST. AND. 255 


PORT 


B ADDR <L) 


335 




DEFB 


DMAWR5+AUT0RS+CE 


dAIT 




336 




DEFB 


0C7H 


WR6, 


RESET A TIMING 


337 




DEFB 


OCBH 


WR6, 


RESET B TIMING 


338 




DEFB 


OCFH 


WR6, 


LOAD PORT B 


339 




DEFB 


DMAWRO+XFER+A B 


A -> 


B 


340 




DEFB 


OCFH 


WR6, 


LOAD COUNTERS 


341 


DM^ND- 


EQU 


* 






342 












343 


SIOTA: 










344 




DEFB 


SIOWRO 


CH. RESET 


345 




DEFB 


CHRES 






346 




DEFB 


SI0WR1 


RDY/WAIT, INT. MODE 


347 




DEFB 


WREN+RDY+RXIAP 






348 




DEFB 


SI0WR4 


MODE 




349 




DEFB 


X 1 +ST0P2+EVEN+P AR ITY 




350 




DEFB 


SI0WR5 


TX PARAMS. 


351 




DEFB 


DTR+TX7+TXEN+RTS 






352 




DEFB 


SI0WR3 


RX PARAMS. 


353 




DEFB 


RX7 






354 


SIOEA: 


EQU 


* 






355 












356 


SIOTB: 
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DMAS 10 






PAGE 8 


LOC 


OBJ CODE M STMT 


SOURCE 


STATEMENT 




ASM 5. 9 


OlOF 


00 


357 




DEFB 




SIOWRO 


i CH. RESET 


QUO 


18 


358 




DEFB 




CHRES 




0111 


01 


359 




DEFB 




SI0WR1 


; STATUS AFFECTS VECTOR 


0112 


04 


360 




DEFB 




SIOSAV 




0113 


02 


361 




DEFB 




SI0WR2 


; VECTOR 


0114 


10 


362 




DEFB 




SIOVEC AND. 255 








363 


SIOEB. 


EQU 




* 








364 


*EJ 














365 
















366 


; , 


DATA 


AREA 








367 












2000 




368 




ORG 




RAM 




2000 




369 


SIOFLG 


: DEFS 




1 


iSIO STATUS FLAG BYTE 


2001 




370 


SRC: 


DEFS 




BLKSIZ 


iDMA SOURCE ADDR 


2041 




371 




DEFS 




64 


i STACK AREA 






372 


STW: 


EQU 




* 








373 
















374 




END 
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SECTION 
1 



Introduction. 

The Z80 Serial Input/Output (SIO) controller 
is designed for use in a wide variety of serial- 
to-parallel input and parallel-to-serial output 
applications. In this application note, only 
asynchronous applications are considered. The 
emphasis is almost completely on software 



implementation, with only modest reference to 
hardware considerations. 

While reference is made only to the 
Z80 SIO, the entire text also applies to the 
Z80 DART, which is functionally identical to 
the Z80 SIO in asynchronous applications. 



Protocol Communication, either on an external data 

link or to a local peripheral, occurs in one of 
two basic formats: synchronous or asyn- 
chronous. In synchronous communication, a 
message is sent as a continuous string of 
characters where the string is preceded and 
terminated by control characters; the pre- 
ceding control characters are used by the 
receiving device to synchronize its clock with 
the transmitter's clock. In asynchronous com- 
munication, which is described in this applica- 
tion note, there is no attempt at synchronizing 
the clocks on the transmitting and receiving 
devices. Instead, each fixed-length character 
(rather than character string) is preceded and 
terminated by "framing bits" that identify the 
beginning and end of the character. The time 
between bits within a character is approx- 
imately constant, since the clocks or "baud 
rates" in the transmitter and receiver are 
selected to be the same, but the time between 



characters can vary. 

Thus, in asynchronous communication, each 
character to be transmitted is preceded by a 
"start" framing bit and followed by one or 
more "stop" framing bits. A start bit is a 
logical and a stop bit is a logical 1 . The 
receiver will look for a start bit, assemble the 
character up to the number of bits the SIO has 
been programmed for, and then expect to find 
a stop bit. The time between the start and stop 
bits is approximately constant, but the time 
between characters can vary. When one char- 
acter ends, the receiving device will wait idly 
for the start of the next character while the 
transmitter continues to send stop or 
"marking" bits (both the stop bits and the 
marking bits are logical 1). Figure 1 illus- 
trates this. A very common application of asyn- 
chronous communication is with keyboard 
devices, where the time between the operator's 
keystrokes can vary considerably. 



MESSAGE FLOW 



I START I D I 0, I D n I PARITY I STOP 



/>" 



t 



5, 6, 7, OR 8 BITS PER 

CHARACTER RECEIVED 

1, 2, 3, 4, 5, 6, 7, OR 8 BITS PER 

CHARACTER TRANSMITTED 




TIME BETWEEN CHARACTERS VARIES 



Figure 1. Asynchronous Data Format 
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Protocol If the transmitter's clock is slightly faster 

(Continued) than the receiver's clock, the transmitter can 
be programmed to send additional stop bits, 
which will allow the receiver to catch up. If 
the receiver runs slightly faster than the trans- 
mitter, then the receiver will see somewhat 
larger gaps between characters than the trans- 
mitter does, but the characters will normally 



still be received properly. This tolerance of 
minor frequency deviations is an important 
advantage of using asynchronous I/O. Note 
however that errors, called "framing errors," 
can still occur if the transmitter and receiver 
differ substantially in speed, since data bits 
may then be erroneously treated as start or 
stop bits. 



Modes The SIO may be used in one of three modes: 

Polled, Interrupt, or Block Transfer, depend- 
ing on the capabilities of the CPU. In Polled 
mode the CPU reads a status register in the 
SIO periodically to determine if a data 
character has been received or is ready for 
transmission. When the SIO is ready, the CPU 
handles the transfer withm its mam program. 

In Interrupt mode, which is far more com- 
mon, the SIO informs the CPU via an interrupt 
signal that a single-character transfer is 
required. To accomplish this, the CPU must be 
able to check for the presence of interrupt 
signals (or "interrupt requests") at the end of 
most instruction cycles. When the CPU detects 
an interrupt it branches to an interrupt service 
routine which handles the single-character 
transfer. The beginning memory address of 
this interrupt service routine can be derived, 
in part, from an "interrupt vector" (8-bit byte) 
supplied by the SIO during the interrupt 
acknowledge cycle. 

In Block Transfer mode, the SIO is used in 



conjunction with a DMA (direct memory 
access) controller or with the Z80 or Z8000 
CPU block transfer instructions for very fast 
transfers. The SIO interrupts the CPU or DMA 
only when the first character of a message 
becomes available, and thereafter the SIO uses 
only its Wait/Ready output pin to signal its 
readiness for subsequent character transfers. 
Due to the faster transfer speeds achievable, 
Block Transfer mode is most commonly used in 
synchronous communication and only rarely in 
asynchronous formats. It is therefore not 
treated with specific examples in this applica- 
tion note. 

Since Polled mode requires CPU overhead 
regardless of whether or not an I/O device 
desires attention, Interrupt mode is usually the 
preferred alternative when it is supported by 
the CPU. Note that the choice of Polled or 
Interrupt mode is independent of the choice of 
synchronous or asynchronous I/O. This latter 
choice is usually determined by the type of 
device to which the system is communicating. 



SIO Con- The SIO comes in four different 40-pin 

figurations configurations: SIO/0, SIO/1, SIO/2, and 
SIO/9. The first three of these support two 
independent full-duplex channels, each with 
separate control and status registers used by 
the CPU to write control bytes and read status 
bytes. The SIO/9 differs from the first three 
versions in that it supports only one full-duplex 
channel. The product specifications for these 



versions explain this m full. 

There are 41 different signals needed for 
complete two-channel implementation in the 
SIO/0, SIO/1, and SIO/2, but only 40 pins are 
available. Therefore, the versions differ by 
either omitting one signal or bonding two 
signals together. The dual-channel asyn- 
chronous-only Z80 DART has the same pm 
configuration as the SIO/0. 



SIO-CPU The serial-to-parallel and parallel-to-serial 

Hardware conversions required for serial I/O are per- 

Interfacing formed automatically by the SIO. The device is 
connected to a CPU by an 8-bit bidirectional 
data path, plus interrupt and I/O control 
signals. 

The SIO was designed to interface easily to 
a Z80 CPU, as shown in Figure 2. Other 
microprocessors require a small amount of 
external logic to generate the necessary inter- 
face signals. 

The SIO provides a sophisticated vectored- 
interrupt facility to signal events that require 
CPU intervention. The interrupt structure is 
based on the Z80 peripheral daisy chain. Non- 
Z80 microprocessors that are unable to utilize 
external vectored interrupts require some 



additional external logic to utilize efficiently 
this interrupt facility. Some non-Z80 system 
designs do not utilize the vectored interrupt 
structure of the SIO at all. Instead, these 
require the CPU to poll the SIO's status 
through the data bus or to use non-vectored 
SIO interrupts. 

Microprocessors such as the 8080 and 6800 
need some signal translation logic to generate 
SIO read/write and clock timing. CPU signals 
which synchronize a peripheral device read or 
write operation are gated to form the proper 
I/O signals for the SIO. The SIO is selected 
by some processor-dependent function of the 
address bus in a memory or I/O addressing 
space. 
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Reference In the next section we begin with a dis- 

Material cussion of features common to all forms of 

asynchronous I/O. This is followed by discus- 
sions of polled asynchronous I/O and interrupt 
asynchronous I/O. Next is a series of fre- 
quently asked questions about the SIO when 
used in asynchronous applications. Finally, an 
example of a simple interrupt-driven asyn- 
chronous application is given and discussed in 
detail. For a complete understanding of the 



material covered, the following publications 
are needed: 

■ Z80 SIO Product Specification or Z80 DART 

Product Specification 

m Z80 SIO Technical Manual 

■ Z80 Family Program Interrupt Structure 
M Z80 CPU Technical Manual 

■ Z80 Assembly Language Programming 

Manual 
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Figure 2. SIO Hardware Interfacing 
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SECTION 

2 



Operational Considerations. 

All of the SIO options to be discussed here 
are software controllable and are set by the 
CPU. Thus, use of the SIO begins with an 
initialization phase where the various options 
are set by writing control bytes. These options 
are established separately for each of the two 



channels supported by the SIO if both chan- 
nels are used. Before giving an overview of 
how initialization is done, we will describe 
some of the basic characteristics of SIO oper- 
ations that are common to both the Polled and 
Interrupt-driven modes. 



Addressing The CPU must have a means to identify any 

the SIO specific I/O device, including any attached 

SIO. In a Z80 CPU environment, this is done 
by using the lower 8 bits of the address bus 
(Ao-A7)._Typically, the A\ bit is wired to the 
SIO's B/A input pin for selecting access to 
Channel A or Channel B, and the Aq bit is 
wired to the SIO's C/D input pin for selecting 
the use of the data bus as an avenue for 
transferring control/status information (C) or 
actual data messages (D). The remaining bits 
of the address bus, A2-A7, contain a port 
address that uniguely identifies the SIO 



device. These latter six lines are usually wired 
to an external decoding chip which activates 
that SIO's Chip Enable (CE) input pin when its 
address appears on A2-A7 of the address bus. 
The bar notation drawn above_the names of 
certain signal lines, such as B/A and C/D, 
refer to signals which are interpreted as active 
when their logic sense — and voltage level — is 
Low. For example, the B/A pin specifies Chan- 
nel B of the SIO when it carries a logic 1 (high 
voltage) and it specifies Channel A when it 
carries a logic (low voltage). 



Asynch- Bits per Character. The SIO can receive or 

ronous transmit 5, 6, 7, or 8 bits per character. This 

Format can be different for transmission and recep- 

Operations tion, and different for each channel. ASCII 

characters, for example, are usually transmit- 
ted as 7 bits. The SIO can m fact transmit 
fewer than 5 bits per character when set to the 
5-bit mode; this is discussed further in the sec- 
tion entitled "Questions and Answers." 

Parity. A parity bit is an additional bit added 
to a character for error checking. The parity 
bit is set to or 1 in order to make the total 
number of Is in the character (including parity 
bit) even or odd, depending on whether even 
or odd parity is selected. The SIO can be set 
either to add an optional parity bit to the "bits 
per character" described above, or not to add 
such a bit. When a parity bit is included, 
either even or odd parity can be chosen. This 



selection can be made independently for each 
channel. 

Start and Stop Bits. There are two types of 
framing bits for each character: start and stop. 
When transmitting asynchronously, the SIO 
automatically inserts one start bit (logic 0) at 
the beginning of each character transmitted. 
The SIO can be programmed to set the 
number of stop bits inserted at the end of each 
character to either 1, Wi , or 2. The receiver 
always checks for 1 stop bit. Stop bits refer to 
the length of time that the stop value, a logic 
1 , will be transmitted; thus 1 V2 stop bits means 
that a 1 will be transmitted for the length of 
clock time that 1 V2 bits would normally take 
up. A logic 1 level that continues after the 
specified number of stop bits is called a 
"marking" condition or "mark bits." 



CPU-SIO The SIO always passes 8-bit bytes to the 

Character CPU for each character received, no matter 

Transfers how many "bits per character" are specified in 

the SIO initialization phase. If the number of 
"bits per character" is less than eight, parity 
and/or stop bits will be included in the byte 
sent to the CPU. The received character starts 
with the least-significant bit (Do) and continues 
to the most-significant bit; it is immediately 



followed by the parity bit (if parity is enabled) 
and by the stop bit, which will be logic 1 
unless there is a framing error. The remainder 
of the byte, if space is still available, is filled 
with logic Is (marking). If the "bits per char- 
acter" is eight, then the byte sent to the CPU 
will contain only the data bits. In all cases, the 
start bit is stripped off by the SIO and is not 
transmitted to the CPU. 



Clock The SIO has five input pins for clock 

Divider signals. One of these inputs (CLK) is used 

only for internal timing and does not affect 
transmission or rece ption rates. The other four 
clock i nputs (RxCA, TxCA, RxCB, and 
TxCB) are used for timing the reception and 
transmission rates in Channels A and B. Only 
these last four are involved in "clock divid- 
ing." A clock divider within the SIO can be 



programmed to cause reception/transmission 
clocking at the actual input clock rate or at 
1/16, 1/32, or 1/64 of the input clock rate. The 
receiver and transmitter clock divisions within 
a given channel must be the same, although 
their input clock rates can be different. The xl 
clock rate can be used only if the transitions of 
the Receive clock are synchronized to occur 
during valid data bit times. 
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Auto The SIO has an Auto Enables feature that 

Enables allows automatic SIO response and telephone 

answering. When Auto Enables is set for a par- 
ticular channel, a transition to logical (Low 
input level) on the respective Data Carrier 



Detect (DCD) input will enable reception, and 
a transiti on to logical on the respective Clear 
To Send (CTS ) input will enable transmission. 
This is described below under the heading 
"Modem Control." 



Special There are three error conditions that can 

Receive occur when the SIO is receiving data. Each of 

Conditions these will cause a status bit to be set, and if 
operating in Interrupt mode, the SIO can 
optionally be programmed to interrupt the 
CPU on such an error. The error conditions 
are called "special receive conditions" and 
they include: 

■ Framing error. If a stop bit is not detected 
in its correct location after the parity bit (if 
used) or after the most-significant data bit 
(if parity is not used), a framing error will 
result. The start bit preceding the char- 
acter's data bits is not considered in deter- 
mining a framing error, although character 
assembly will not begin until a start bit is 
detected. 



I Parity error. If parity bits are attached by 
the external I/O device and checked by the 
SIO while receiving characters, a parity 
error will occur whenever the number of 
logic 1 data bits in the character (including 
the parity bit) does not correspond to the 
odd/even setting of the parity-checking 
function. 

Receiver overrun error. SIO buffers can 
hold up to three characters. If a character is 
received when the buffers are full (i.e., 
characters have not been read by the CPU), 
an SIO receiver overrun error will result. In 
this case, the most recently received char- 
acter overwrites the next most recently 
received character. 



Modem Five signal lines on the SIO are provided 

Control for optional modem control, although these 

lines can also be used for other general- 
purpose control functions. They are: 

RTS (Request To Send). An output from the 
SIO to tell its modem that the SIO is ready to 
transmit data. 

DTR (Data Terminal Ready). An output from 
the SIO to tell its modem that the SIO is ready 
to receive data. 

CTS (Clear To Send). An input to the SIO 
from its modem that enables SIO transmission 
if the Auto Enables function is used. 



DCD (Data Carrier Detect). An input to the 
SIO from its modem that enables SIO recep- 
tion if the Auto Enables function is used. 



SIO 
(CHANNEL A) 



TRANSMITTER 



REQUEST TO SEND 
CLEAR TO SEND 



DATA TERMINAL READY 
DATA CARRIER DETECT 



SYNC (Synchronization). A spare input to the 
SIO in asynchronous applications. This input 
may be used for the Ring Indicator function, if 
necessary, or for general-purpose inputs. 

In most applications of asynchronous I/O 
that use modems, the RTS and DTR control 
lines and the Auto Enables function are acti- 
vated during the initialization sequence, and 
they are left active until no further I/O is 
expected. This causes the SIO to tell its 
modem continuously that the SIO is ready to 
transmit and receive data, and it allows the 
modem to enable automatically the SIO's trans- 
mission and reception of data. Figure 3 illus- 
trates this. 



Figure 3. Modem Control (Single Channel) 



26-0003-0342 
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External/ A change in the status of certain external 

Status inputs to the SIO will cause status bits in the 

Interrupts SIO to be set. In the Polled Mode, these status 

bits can be read by the CPU. In the Interrupt 
mode, the SIO can also be programmed to 
interrupt the CPU when the change occurs. 
There are three such "external/status" condi- 
tions that can cause these events: 

■ DCD. Reflects the value of the DCD input. 

■ CTS. Reflects the value of the CTS input. 

■ Break. A series of logic or "spacing" bits. 



Note that the DCD and CTS status bits are 
the inverse of the SIO li nes, i.e., the DCD bit 
will be 1 when the DCD line is Low. 

Any transition in any direction (i.e., to logic 
or to logic 1) on any of these inputs to the 
SIO will cause the related status bit to be 
latched and (optionally) cause an interrupt. 
The SIO status bits are latched after a transi- 
tion on any one of them. The status must be 
reset (using an SIO command) before new 
transitions can be reflected in the status bits. 



Initialization The SIO contains eight write registers for 
Channel B (WR0-WR7) and seven write 
registers for Channel A (all except write 
register WR2). These are described fully in 
the Z80 SIO Technical Manual and are 
summarized in Appendix B. The registers are 
programmed separately for each channel to 
configure the functional personality of the 
channel. WR2 exists only in the Channel B 
register set and contains the interrupt vector 
for both channels. Bits in each register are 
named D7 (most significant) through Dq. With 
the exception of WRO, programming the write 
registers reguires two bytes: the first byte is to 
WRO and contains pointer bits for selection of 
one of the other registers; the second byte is 
written to the register selected. WRO is a 
special case in that all of the basic commands 
can be written to it with a single byte. 

There are also three read registers, named 
RRO through RR2, from which status results 
of operations can be read by the CPU (see 
Appendix B). Both channels have a set of 



read registers, but register RR2 exists only in 
Channel B. 

Let us now look at the typical sequence of 
write registers that are loaded to initialize 
the SIO for either Polled or Interrupt-driven 
asynchronous I/O. Figure 4 illustrates the 
sequence. Except for step E, this loading is 
done for each channel when both are used. 
Steps E and F are described further in the sec- 
tion on u Interrupt-Driven Environments." 

Registers WR6 and WR7 are not used in 
asynchronous I/O. They apply only to syn- 
chronous communication. 

The related publications on the SIO should 
be referred to at this point. They will be 
necessary in following the discussion of func- 
tions. In particular, the following material 
should be reviewed: 

Z80 SIO Technical Manual, pages 9-12 
("Asynchronous Operation") 

Z80 SIO Technical Manual, pages 29-37 
("Z80 SIO Programming") 



A. Load WRO. This is done to reset the SIO 

B. Load WR4. This specifies the clock divider, number of 
stop bits, and parity selection Since register WR4 
establishes the general form of I/O for which the SIO is to 
be used, it is best to set WR4 values first 

C. Load WR3. This specifies the number of receive bits 
per character, Auto Enable selection, and turns on the 
receiver enabling bit 

D. Load WR5. This specifies the number of transmit bits 
per character, turns off the bit that transmits the Break 
signal, turns on the bits indicating Data Terminal Ready 
and Reguest To Send, and turns on the transmitter 
enabling bit. 

E. Load WR2. (Interrupt mode only and Channel B only.) 
This specifies the interrupt vector 

F. Load WR1. (Interrupt mode only ) This specifies 
various interrupt-handling options that will be explained 
later. 



NOTES 

Steps A through F are performed in sequence 

* Channel B only 

TInterrupt mode only Polling mode begins I/O after step D 
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Figure 4. Typical Initialization Sequence (One Channel) 
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SECTION 

3 



Polled Environments. 

In a typical Polled environment, the SIO is 
initialized and then periodically checked for 
completion of an I/O operation. Of course, if 
the checking is not frequent enough, received 
characters may be lost or the transmitter may 
be operated at a slower data rate than that of 



which it is capable. Initialization for Polled I/O 
follows the general outline described in the 
last section. We now give an overview of 
routines necessary for the CPU to check 
whether a character has been received by the 
SIO or whether the SIO is ready to transmit a 
character. 



Character To check whether a character has been 

Reception received, and to obtain a received character if 

one is available, the sequence illustrated in 
Figure 5 should be followed after the SIO is 
initialized. We assume that reception was 
enabled during initialization; if it was not, the 
Rx Enable bit in register WR3 must be turned 
on before reception can occur. This must be 
done for each channel to be checked. 

Bit D of register RRO is set to 1 by the SIO 
if there is at least one character available to be 
received. The SIO contains a three-character 
input buffer for each channel, so more than 
one character may be available to be received. 
Removing the last available character from the 
read buffer for a particular channel turns off 
bit D . 

If bit Do of register RRO is 0, then no 
character is available to be received. In this 
case it is recommended that checks be made of 
bit D7 to determine if a Break sequence (null 
character plus a framing error) has been 
received. If so, a Reset External/Status Inter- 
rupts command should be given; this will set 
the External/Status bits in register RRO to the 
values of the signals currently being received. 
Thus, if the Break sequence has terminated, 
the next check of bit D7 will so indicate. It may 
also be desirable to check bit 3 of register RRO 
which reports the value of the Data Carrier 
Detect (DCD) bit. 



In any case, if bit Dq of register RRO is 0, 
polled receive processing terminates with no 
character to receive. Depending on the facil- 
ities of the associated CPU, this step may be 
repeated until a character is available (or 
possibly a time-out occurs), or the CPU 
may return to other tasks and repeat this 
process later. 

If bit Dq of register RRO is 1 , then at least 
one character is available to be read. In this 
case, the value of register RR1 should first be 
read and stored to avoid losing any error infor- 
mation (the manner m which it is read is 
explained later). The character in the data 
register is then read. Note that the character 
must be read to clear the buffer even if there is 
an error found. 

Finally, it is necessary to check the value 
stored from register RR1 to determine if the 
character received was valid. Up to three bits 
need to be checked: bit 6 is set to 1 for a 
framing error, bit 5 is set to 1 for a receiver 
overrun error (which occurs when the receive 
buffers are overwritten, i.e., no character has 
been removed and more than three characters 
have been received), and bit 4 is set to 1 for a 
parity error (if parity is enabled at initial- 
ization time). In case of a receiver overrun or 
parity error, an Error Reset command must be 
given to reset the bits. 




Figure 5. Polled Receive Routine 
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Character To check that an initialized SIO is ready to 

Transmission transmit a character on a channel, and if so to 
transmit the character, the steps illustrated in 
Figure 6 should be followed. We assume that 
the Request To Send (RTS) bit m WR5, if 
required by the external receiving device, 
and the Transmit (Tx) Enable bit were set at 
initialization. 

Depending on the external receiving device, 
the following bits in register RRO should be 
checked: bit 3 (DCD), to determine if a data 
carrier has been detected; bit 5 (CTS), to 
determine if the device has signalled that it is 
clear to send; and bit 7 (Break), to determine 
if a Break sequence has been received. If any 
of these situations have occurred, the bits in 
register RRO must be reset by sending the 
Reset External/Status Interrupts command, and 
the transmit sequence must be started again. 

Next, bit 2 of register RRO is checked. If this 
bit is 0, then the transmit buffer is not empty 
and a new character cannot yet be transmitted. 
Depending on the capabilities of the CPU, this 
is repeated until a character can be trans- 
mitted (or a timeout occurs), or the CPU may 
return to other tasks and start again later. 

If bit 2 of register RRO is 1 , then the transmit 
buffer is empty and the CPU may pass the 



character to be transmitted to the SIO, com- 
pleting the transmit processing. On the 
Z80 CPU, this is done with an OUT instruction 
to the SIO data port. 




Figure 6. Polled Transmit 



Assumptions Now let us consider some examples in more 
for an detail. We assume we are given an external 

Example device to which we will input and output 8-bit 

characters, with odd parity, using the Auto 
Enables feature. We will support this device 
with I/O polling routines following the patterns 
illustrated in Figures 5 and 6. We assume that 
the CPU will provide space to receive char- 
acters from the SIO as fast as the characters 
are received by the SIO, and that the CPU will 
transfer characters as fast as the output can be 
accomplished by the SIO. 



We specify this example by giving the con- 
trol bytes (commands) written to the SIO and 
the status bytes that must be read from the 
SIO. Recall that to write a command to a regis- 
ter, except register WRO, the number of the 
register to be written is first sent to register 
WRO; the following byte will be sent to the 
named register. Similarly, to read a register 
other than RRO (the default), the number of the 
register to be read is sent to register WRO; the 
following byte will return the register named. 



Initialization We begin with the initialization code for the 
SIO. This follows the outline illustrated m 
Figure 4. In the following sample code, each 
time register WRO is changed to point to 
another register, the Reset External/Status 
Interrupts command is given simultaneously. 
Whenever a transition on any of the external 
lines occurs, the bits reporting such a transi- 
tion are latched until the Reset External/Status 
Interrupts command is given. Up to two transi- 
tions can be remembered by the SIO. There- 
fore, it is desirable to do at least two different 



Reset External/Status Interrupts commands as 
late as possible in the initialization so that the 
status bits reflect the most recent information. 
Since it doesn't hurt, we include these com- 
mands each time WRO is changed to point to 
another register. This is an easy way to code 
the initialization to insure that the appropriate 
resets occur. 

In the example below, the logic states on the 
C/D control line and the system data bus 
(D7-D0) are illustrated, together with 
comments. 



2-54 



Initialization _ Bits sent to the SIO 

(Continued) C/D D 7 D 6 D 5 D 4 D 3 D 2 D x D 
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Effects and Comments 

Channel Reset command sent to register WRO (D5-D3). 

Point WRO to WR4 (D 2 -D ) and issue a Reset External/ 
Status Interrupts command (D5-D3). Throughout the 
initialization, whenever we point WRO to another 
register, we will also issue this command for the 
reasons noted above. 

Set WR4 to indicate the following parameters (from left 
to right): 

A. Run at 1/64 the input clock rate (D 7 -De). 

B. Disable the sync bits and send out 2 stop bits per 
character (D5-D2). 

C. Enable odd parity (Dj-Dq). 

Point WRO to WR3. 

Set WR3 to indicate the following: 

A. 8-bit characters to be received (D7-D6). 

B. Auto Enables on (D5). 

C. Receive (Rx) Enable on (Do). 



Point WRO to WR5. 



Set WR5 to indicate the following: 

A. Data Terminal Ready (DTR) on (D 7 ). 

B. 8-bit characters to be transmitted (D6-D5). 

C. Break not to be transmitted (D4). 

D. Transmit (Tx) Enable on (D3). 

E. Request To Send (RTS) on (D^. 



Reset and In the receive and transmit routines that fol- 

Error low, we treat errors such as a transition on the 

Sequences Data Carrier Detect line by calling for a "reset 
sequence" to set the values in read register 
RRO to reflect the current values found at 
the pins. This sequence consists of giving 
the Reset External/Status Interrupts com- 
mand and beginning the driver over again. 
The command takes the form of a write to 
register WRO: 
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Do 
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Permits the status bits in RRO to reflect current status. 

This command does not turn off the latches 
for such things as parity errors stored in bits 
4-6 of register RR1. When such an error 
occurs and the latches must be reset, we will 



call for an u error sequence." This sequence 
consists of giving the Error Reset command 
and beginning the driver over again. The 
command also takes the form of a write to 
register WRO: 
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Resets the latches m register RRL 

When specifying the result of reading 
register RRO or RR1 or specifying data, we will 
indicate the values read as follows: 
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Read a byte from the designated register. . 



Receive and Now we will first give an example 

Transmit of the receive routine. This parallels the 

Routines preceding discussion of "Character 

Reception." 

The framing error in this routine is reported 

on a character-by-character basis and it is not 



necessary to execute an "error sequence" if it 
is the only error received. However, it is not 
harmful to do so. 

Next, we give an example of transmission 
code that parallels the above discussion on 
"Character Transmission." 
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Receive and 

Transmit 

Routines 

(Continued) 
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Effects and Comments (Receive Routine) 

Read a byte from RRO (the default read register); if 
Dg = then no character is ready to be received. In 
this case, if D 7 (Break) or D3 (Data Carrier Detect) 
have changed state, then execute a "reset sequence." 
If Dg = and D7 and D3 have not changed state, then 
no character is ready to be received, either loop on 
this read or try again later. 

Point WRO to read from RR1, we will now check for 
errors in the character read Note that Reset Exter- 
nal/Status Interrupt Commands are not done normally 
to avoid losing a line-status change. 

Read a byte from RR1; if either bit Dq= 1 (framing 
error), Ds= (receive overrun error), or D 4 = 1 
(parity error), the character is invalid and an "error 
sequence" should be executed after the following step. 

Read in the data byte received. This must be done to 
clear the SIO buffer even if an error is detected. 
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1 


D 


D 


D 


D 


D 


D 


D 


D 























D 


D 


D 


D 


D 


D 


D 


D 



Effects and Comments (Transmit Routine) 

Read a byte from RRO; if either bit D3 (Data Carrier 
Detect), D5 (Clear To Send) or D7 (Break) have 
changed state, a "reset sequence" should be executed. 
If D3, D5 and D7 have not changed state, then if 
D2 = 0, the transmit buffer is not yet empty and 
a transmit cannot take place; either loop, reading RRO, 
or try again later. 

Send the data byte to be transmitted. 



SECTION 
4 



Interrupt-Driven Environments. 

In a typical interrupt-driven environment, 
the SIO is initialized and the first transmission, 
if any, is begun. Thereafter, further I/O is 
interrupt driven. When action by the CPU is 
needed, an SIO interrupt causes the CPU to 
branch to an interrupt service routine after the 
CPU first saves state information. 

In common usage, if I/O is interrupt driven, 
all interrupts are enabled and each different 
type of interrupt is used to cause a CPU 
branch to a different memory address. There is 
perhaps one frequent exception to this: parity 
errors are sometimes checked only at the end 
of a sequence of characters. The SIO facili- 
tates this kind of operation since the parity 
error bit in read register RR1 is latched; once 
the bit is set it is not reset until an explicit 



reset operation is done. Thus, if a parity error 
has occurred on any character since last reset, 
bit 4 in register RR1 will be set. It is then 
possible to set register WR1 so that parity 
errors do not cause an error interrupt when a 
character is received. The user then has the 
obligation to poll for the value of the parity 
bit upon completion of the sequence. 

SIO initialization for Interrupt mode nor- 
mally requires two steps not used in Polled 
mode: an interrupt vector (if used) must be 
stored in write register WR2 of Channel B and 
write register WR1 must be initialized to 
specify the form of interrupt handling. It is 
preferable to initialize the interrupt vector in 
WR2 first. In this way an interrupt that arrives 
after the enabling bits are set in WR1 will 
cause proper interrupt servicing. 



Interrupt The interrupt vector, register WR2 of Chan- 

Vectors nel B, is an 8- bit memory address. When an 

interrupt occurs (and note that an interrupt 
can only occur after interrupts have been 
enabled by writing to register WR1) the inter- 
rupt vector is normally taken as one byte of an 
address used by the CPU to find the location 
of the interrupt service routine. It is also 
possible to cause the particular type of inter- 
rupt condition to modify the address vector in 
WR2 before branching, resulting in a branch 



to a different memory location for each inter- 
rupt condition. This is a very useful construct; 
it permits short, special-purpose interrupt 
routines. The alternative, to have one general- 
purpose interrupt routine which must deter- 
mine the situation before proceeding, can be 
quite inefficient. This is usually undesirable 
since the speed of interrupt-service routines is 
often a critical factor in determining system 
performance. 
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Interrupt There are at most eight different types of 

Vectors interrupts that the SIO may cause, four for 

(Continued) each of the two channels. If bit 1 in register 

WR1 of Channel B has been turned on so that 
an interrupt will modify the interrupt vector, 
the three bits (1-3) of the vector will be 
changed to reflect the particular type of inter- 
rupt. These interrupts follow a hardware-set 
priority as follows, starting with the highest 
priority: 

Channel A Special Receive Condition sets bits 
3-1 of WR1 to 111, 

Channel A Character Received sets bits 3-1 
to 110, 

Channel A Transmit Buffer Empty sets bits 3-1 
to 100, 

Channel A External/Status Transition sets bits 
3-1 to 101. 

Channel B Special Receive Condition sets bits 
3-1 to Oil, 

Channel B Character Received sets bits 3-1 
to 010, 

Channel B Transmit Buffer Empty sets bits 3-1 
to 000, 

Channel B External/Status Transition sets bits 
3-1 to 001. 

For example, suppose that the interrupt vec- 
tor had the value 11110001 and the Status 
Affects Vector bit is enabled, along with all 
interrupt-enable bits. When an External/Status 
transition occurs m Channel A, the three zeros 
(bits 3-1) would be modified to 101, yielding 
an interrupt vector of 11111011. The value of 
the interrupt vector, as modified, may be 
tained by reading register RR2 in Channel B. 



Note that when a character is received, 
either the Special Receive Condition or Rx 
Character Available interrupt will occur, 
depending on whether or not an error 
occurred; the two will never occur simul- 
taneously. Therefore, these two interrupts have 
egual priority. Note also that you can select 
not to be interrupted on some of the eight con- 
ditions; in this case, the presence of a par- 
ticular condition for which interrupts are not 
desired can be determined by polling. 

Suppose that interrupts have been enabled 
for all possible cases, and that the Status 
Affects Vector bit has also been enabled, 
allowing a different routine to handle each 
possible interrupt. As each interrupt causes a 
branch to a location only two bytes higher than 
the last interrupt, it is not possible to place a 
routine directly at the location where the vec- 
tored interrupt branches. In a Z80 CPU envi- 
ronment, these addresses refer to a table in 
memory which contains the actual starting 
location of the interrupt service routine. Also, 
since the state information saved by a CPU is 
rarely all of the information necessary to prop- 
erly preserve a computation state, a typical 
interrupt service routine will begin by saving 
additional information and end by restoring 
that information. This is shown briefly in the 
examples of code m Appendix A. 

It is possible to connect several SIOs using 
the interrupt mechanism and the IEI and IEO 
lines on the SIO to determine a priority for 
interrupt service. This mechanism is discussed 
on page 42 of the Z80 SIO Technical Manual 
and in the Z80 Family Program Interrupt 
Structure Manual. We do not go into it further 
in this application note. 



Initialization In general, the initialization procedure 

illustrated in Figure 4 can still be followed. All 
six steps (A through F) are reguired here. 
After completing the first four steps, which are 
the same as initialization for polled I/O, it is 
necessary to load an interrupt vector into WR2 
of Channel B. Information is then written into 
register WR1 specifying which interrupts are 
to be enabled and whether a specific kind of 
interrupt should modify the interrupt vector. 

Now let us give an example. As in the polled 
example, we assume that we are given a 
device to which we will input and output 8-bit 
characters, with odd parity, using the Auto 
Enables feature. We also assume the CPU will 
provide space to store characters as received. 

We do not discuss the SIO commands and 
registers in detail. This is done in the Z80 SIO 
Technical Manual. A summary of the register 
bit assignments taken from the Z80 SIO Serial 
Input/Output Product Specilication is included 
at the end of this note. Recall that to write a 



register other than register WR0, the number 
of the register to be written is first sent to 
register WR0, and the following byte will be 
sent to the named register. Similarly, to read a 
register other than RR0 (the default), the 
number of the register to be read is first writ- 
ten to register WR0 and the next byte read will 
return the contents of the register named. 

In our example below, each time register 
WR0 is changed to point to another register, 
the Reset External/Status Interrupts command 
is also given. Whenever a transition on any of 
the external/status lines occurs, the bits report- 
ing the transition are latched until the Reset 
External/Status Interrupts command is given. 
Up to two transitions can be remembered by 
the internal logic of the SIO. Therefore, it is 
desirable to do at least two different Reset 
External/Status Interrupt commands as late as 
possible in the initialization so that the status 
bits reflect the most recent information. Since 
it doesn't hurt, we give these commands each 
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Initialization time WRO is changed to point to another reg- 
(Continued) ister. This is an easy way to code the initial- 
ization to assure that the appropriate resets 
occur. 



The columns below show the logic states on 
the C/D control line and the system data bus 
(D7-Dq), together with comments. 
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Effects and Comments 

Channel Reset command sent to register WRO (D5-D3). 

Point WRO to WR4 (D 2 -D ) and issue a Reset Exter- 
nal/Status Interrupts command (D5-D3). Throughout 
the initialization, whenever we point WRO to another 
register we will also issue a Reset External/Status 
Interrupts command for the reasons noted above. 

Set WR4 to indicate the following parameters (from left 
to right): 

A. Run at 1/64 the clock rate (D 7 -D 6 ). 

B. Disable the sync bits and send out 2 stop bits per 
character (D5-D2). 

C. Enable odd parity (Dj-Dq). 

Point WRO to WR3. 

Set WR3 to indicate the following: 

A. 8-bit characters to be received (D7-D5). 

B. Auto Enables on (D5). 

C. Rx Enable on (D ). 

Point WRO to WR5. 

Set WR5 to indicate the following: 

A. Data Terminal Ready (DTR) on (D 7 ). 

B. 8-bit characters to be transmitted (D5-D5). 

C. Break not to be transmitted (D4). 

D. Tx Enable on (D3). 

E. Reguest To Send (RTS) on (D^. 

Point WRO to WR2 (Channel B only). 

Set the interrupt vector to point to address 11100000 
(which is hex E0 and decimal 224). Once interrupts 
are enabled, they will cause a branch to this memory 
location, modified as described above if the Status 
Affects Vector bit is turned on (which it will be here). 
This vector is only set for Channel B, but it applies 
to both channels. It has no effect when set in 
Channel A. 

Point WRO to WR1. 

Set WR1 to indicate the following: 

A. Cause interrupts on all characters received, 
treating a parity error as a Special Receive 
Condition interrupt (D4-D3). 

B. Turn on the Status Affects Vector feature, causing 
interrupts to modify the status vector — meaningful 
only on Channel B, but will not hurt if set for 
Channel A (D 2 ). 

C. Enable interrupts due to transmit buffer being 
empty (D\). 

D. Enable External/Status interrupts (Do). 
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Special A Special Receive Condition interrupt 

Receive occurs (a) if a parity error has occurred, (b) if 

Condition there is a receiver overrun error (data is being 

Interrupts overwritten because the channel's three-byte 

receiver buffer is full and a new character is 
being received), or (c) if there is a framing 
error. The processing in this case is the fol- 
lowing: 

1 . Issue an Error Reset command (to register 
WRO) to reset the latches in register RR1. 

2. Read the character from the read buffer and 
discard it to empty the buffer. 

It may be desirable to read and store the 



value of register RR1 to gather statistics on 
performance or determine whether to accept 
the character. In some applications, a 
character may still be acceptable if received 
with a framing error. 

In specifying the result of reading register 
RRO, RR1, or specifying data, we will indicate 
the values as follows: 



D 7 


D 6 


D 5 


D 4 


D 3 


E>2 


Dl 


Do 


D 


D 


D 


D 


D 


D 


D 


D 



Bead a byte from the designated register. 

We now present an example of processing a 
Special Receive Condition interrupt. 



C/D 



D 7 D 6 



Bits sent and received 

D 5 D 4 D3 D 2 D! 



Do 



1 























1 




















1 


D 


D 


D 


D 


D 


D 


D 


D 




















1 








1 


1 



































D 


D 


D 


D 


D 


D 


D 


D 



Effects and Comments 

If we need to know what kind of error occurred, we 
point WRO to read from RR1 . Note that the Reset 
External/Status Interrups command is not used. This 
avoids losing a valid interrupt. 

Read a byte from RR1; one or more of bit D5 (framing 
error), D5 (receive overrun error), or D4 (parity error) 
will be 1 to indicate the specific error. 

Give an Error Reset command to reset all the error 
latches. 

Read m the data byte received This must be done to 
clear the receiver buffer, but the character will gener- 
ally be disregarded. 



Received (Rx) When an Rx Character Available interrupt 
Character occurs, the character need only be read from 

Interrupts the read buffer and stored. If parity is enabled 



with character lengths of 5, 6, or 7 bits, the 
received parity bit will be transferred with the 
character. Any unused bits will be Is. 



External/ To respond to an External/Status Interrupt, 

Status all that is necessary is to send a Reset Exter- 

Interrupts nal/Status Interrupts command. However, if 

you wish to find the specific cause of the 



interrupt, it is necessary to read register RRO. 
In this case, the complete processing takes the 
following form: 



Bits sent and received 



C/D 


D 7 


D 6 


D5 


D 4 


D 3 


D 2 


Dl 


Do 


1 


D 7 


D 6 


D 5 


D 4 


D 3 


D 2 


Dl 


Do 




















1 











1 















Effects and Comments 

Read register RRO; bit D 7 (Break), D 5 (Clear To Send), 
or D3 (Data Carrier Detect) will have had a transition 
to indicate the cause of the interrupt. 

Give a Reset External/Status Interrupts command to set 
the latches in RRO to their current values and stop 
External/Status Interrupts until another transition 



Transmit (Tx) The final kind of interrupt is a Tx Buffer 
Buffer Empty Empty interrupt. If another character is ready 
Interrupts to be transmitted on this channel, a Tx Buffer 

Empty interrupt indicates that it is time to do 
so. To respond to this interrupt, you need only 
send the next character. If no other character 
is ready to transmit, it may be desirable to 
mark the availability of the transmit mechanism 
for future use. In addition, you should send a 
Reset Tx Interrupt Pending command. This 
command prevents further transmitter inter- 



rupts until the next character has been loaded 
into the transmitter buffer. 

The Reset Tx Interrupt Pending command to 
WRO takes the following form: 



D 7 


D 6 


D 5 


D 4 


D 3 


D 2 


Di 


Do 








1 





1 












Beset Tx Interrupt Pending command; no Tx Empty Inter- 
rupts will be given until after the next character has been 
placed m the transmit buffer. 



2-59 



Z80 To take these examples further, let us use 

Assembler Z80 Assembler code to implement the routines 

Code for a single channel. We assume that the loca- 

tion stored in register WR2 points to the 
appropriate interrupt service routine. We also 
assume that the following constants have 
already been defined: 

SlOctrl. The address of the SIO's Channel B 
control port (we assume Channel B in order to 
include code to initialize the interrupt vector). 



SlOdata. The address of the SIO's Channel B 
data port. 

X. An address pointing to locations in memory 
that will be used to store various values. 

We will write data as binary constants; the 
"B" suffix indicates this. In most cases, binary 
constants will be referred to by the command 
names. We begin with the initialization 
routine: 



INIT: 



LD 


C, SlOctrl 


LD 
OUT 


A,00011000B 
(C) ,A 


LD 
OUT 
LD 
OUT 


A,00010100B 
(C) ,A 

A,11001101B 
(C),A 


LD 
OUT 
LD 
OUT 


A,00010011B 
(C) ,A 

A,11100001B 
(C),A 


LD 
OUT 
LD 
OUT 


A,00010101B 
(C) ,A 

A,11101010B 
(C),A 


LD 


A,00010010B 


OUT 
LD 


(C),A 
A,11100000B 


OUT 


(C),A 


LD 
OUT 
LD 
OUT 


A,00010001B 
(C),A 

A,00010111B 
(C),A 



RET 



; place the address of the SIO in the C register for 
; use in subsequent output 
;load Channel Reset command in A register 
;give Channel Reset command 

; write to register WRO pointing it to register WR4 
; output basic I/O parameters to WR4 

; write to register WRO pointing it to register WR3 
; output receive parameters to WR3 

; write to register WRO pointing it to register WR5 
; output transmit parameters to WR5 

; write to register WRO pointing it to register WR2 
; (Channel B only) 

; output the interrupt vector to WR2; in this case it is 
; decimal location 224 

; write to register WRO pointing it to register WR1 
; output interrupt parameters to WR1 

; return from initialization routine 



Now let us look first at some sample codes 
for the Special Receive Condition interrupt 
routine, following the example above. 



SlOspecint: 



PUSH AF 



LD 
OUT 
IN 
LD 


A,00000001B 
(SlOctrl) ; A 
A,(SIOctrl) 
(X),A 


LD 


A,00110000B 


OUT 


(SlOctrl) ,A 


IN 


A,(SIOdata) 


POP 
EI 


AF 



RETI 



This is followed by a simple receive interrupt 
routine that will fetch the character received 
and store it in a temporary location. 

;save registers which will be used in this routine 
; write to register WRO pointing it to register RR1 

; fetch register RR1 

; store result for later error analysis 

;send an Error Reset command to reset device 
; latches 

; fetch the character received — we will discard this 
; character since an error occurred during its 
; reception 

; restore saved registers 
; enable interrupts 

; return from interrupt 
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Z80 

Assembler 

Code 

(Continued) 



SlOrecint: 


PUSH 


AF 




IN 
LD 


A,(SIOdata) 
(X),A 




POP 

EI 

RETI 


AF 



;save registers which will be used in this routine 

;fetch the character received 
; store result for later use 

; restore saved registers 
; enable interrupts 
; return from interrupt 



Of course, this last routine is probably far 
too simple to be useful. It is more likely that 
an interrupt routine will fill up a buffer of 
characters. A more complex example of a 
receive interrupt routine is contained in the 



chapter entitled "A Longer Example." 

We now give a simple interrupt routine for 
an External/Status Interrupt, again assuming 
that the status contents of SIO register RRO are 
stored in temporary location X: 



:: PUSH 


AF 


LD 
OUT 


A,00010000B 
(SlOctrl) ,A 


IN 
LD 


A,(SIOctrl) 
(X) ,A 


POP 

EI 
RETI 


AF 



,save registers which will be used in this routine 
,send a Reset External/Status Interrupts command 

; fetch register RRO 

; store result for later analysis 

; restore saved registers 
; enable interrupts 
; return from interrupt 



Finally, we give the processing for a 
transmit interrupt routine in the case where no 
more characters are to be transmitted. 

It is likely that this code would just be a por- 
tion of a more general transmit interrupt 

SlOtrmnt: PUSH AF 

LD A,00101000B 

OUT (SlOctrl) ,A 



POP 

EI 

RETI 



AF 



routine which would transmit a buffer-full of 
information at a time. A more complex exam- 
ple is included in the section entitled "A 
Longer Example." 



,save registers which will be used in this routine 
,send a Reset Tx Interrupt Pending command 

, restore saved registers 

, Enable Interrupts 

, Return From Interrupt 
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SECTION 

5 

Hardware 
Considerations 



Questions and Answers. 

Q: Can a sloppy system clock cause prob- 
lems m SIO operation? 

A: Yes; the specifications for the system 
clock are very tight and must be met closely 
to prevent SIO malfunction. The clock high 
voltage must be greater than V CC -0.6V but 
less than -I- 5.5V. The clock low voltage 
must be greater than -0.3V but less than 
+ 0.45 V. The transitions between these two 
levels must be made i n les s tha n 30 ns. This 
does not apply to the RxC and TxC inputs 
which are standard TTL levels. 

Q: When is a received character available to 

be read? 
A: Data will be available a maximum of 13 

syst em c lock cycles from the rising edge of 

the RxC signal which samples the last bit of 

the data. 

Q: What is the maximum time between 

character-insertion for transmission and 

next-character transmission? 
A: This will vary depending on the speed of 

the line over which the character is being 

transmitted. 

Q: Are the control lines to the SIO synchro- 
nous with the system clock so that noise may 
exist on the buses any time before setup 
reguirements are satisfied? 

A: Yes. 

Q: In asynchronous use must receiver and 
transmitter clock rates be the same? 

A; No, the SIO allows receive and transmit 
for each channel to use a different clock 
(thus up to four different clocks for receiv- 
ing and transmitting data can be used on 
each SIO). However, the clock multiplier 
for each channel must be the same. 

Q: Do Wait states have to be added when 
using the SIO with other processors other 
than the Z80 CPU? 



A: No, provided that setup times specified for 
the SIO are met. 

Q: If the Auto Enables bit in regis ter W R3 is 
set, will a change in sta te on the DCD (Data 
Carrier Detect) or CTS (Clear To Send) 
lines still cause an interrupt? 

A: Yes, provided that External/ Status Inter- 
rupts are enabled (bit in register WR1). 

Q: Is the Ml line used by the SIO if no inter- 
rupts are enabled? 

A: No, and in this case the Ml input should 
be tied high. 

Q: Will the SIO continue to interrupt for a 
condition if the condition persists and the 
interrupt remains enabled? 

A: Yes. 

Q: What is the maximum data rate of 
the SIO? 

A: It is 1/5 the rate of the system clock 
(CLK). For example, if the system clock 
operates at 4 MHz, the SIO's maximum 
transfer rate is 800K bits (100K bytes) 
per second. 

Q: What pins are edge sensitive and should 
\ be strapped to avoid strange int errupts ? 

A: The external synchronization (SYNC) pins 
and any other exter nal st atus pins th at are 
not used, including CTS , and DCD. 

Q: What happens if the transmitter or 
receiver is disabled, while processing a 
character, by turning off its associated 
enable bit (bit 3 in register WR5 for transmit 
or bit in register WR3 for receive)? 

A: The transmitter will complete the 

character transmission m an orderly fashion. 
The receiver, however, will not finish. It will 
lose the character being received and no 
interrupt will occur. 



Register Q: Does the Tx Buffer Empty (bit 2 in register 

Contents RRO get set when the last byte in the buffer 

is in the process of being shifted out? 
A: No. The bit is set when the transmit buffer 
has already become empty. Similarly, the 
Tx Buffer Empty interrupt will not occur 
until the buffer is empty. The same is true 
for reception: the Rx Character Available 
bit (bit in register RRO) is not set until the 
entire character is in the receive buffer, and 
the Rx Character Available interrupt will 
not occur until the entire character has 
been moved into the buffer. 

Q: If an Rx Overrun error occurs (and 
bit 5 of register RR1 becomes latched on) 
because a new character has arrived, which 
character gets lost? 



A: The most recently received character 
overwrites the next most recently received 
character. 

Q: Does the Reset External/Status Interrupts 
command reset any of the status bits m 
register RRO? 

A: No. However, when a transition occurs on 
any of the five External/Status bits in 
register RRO, all of the status bits are 
latched in their current position until a 
Reset External/Status Interrupts command is 
issued. Thus, the command does permit the 
appropriate bits of register RRO to reflect 
the current signal values and should be 
done immediately after procebsmg each 
transition on the channel. 
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Special Q: If the CPU does not have the return from 

Uses interrupt sequence (RETI instruction on the 

Z80 CPU), how may the SIO be informed of 
the completion of interrupt handling? 
A: This may be done by writing the Return 
From Interrupt command (binary, 00111000) 
to WR0 in Channel A of the SIO. 

Q. If the CPU can be interrupted but cannot 
be used with vectored interrupts, how 
should processing be done? 

A: Immediately after being interrupted, pro- 
ceed in a manner similar to polling the SIO 
for both receive and transmit. Alternatively, 
the Status Affects Vector bit (bit 2 in 
register WR1) may be set and a byte 
placed into the interrupt vector (register 
WR2 in Channel B). Then, the contents of 
the interrupt vector can be used to deter- 
mine the cause of the interrupt and the 
channel on which the interrupt occurred. 
This can be queried by reading register RR1 
of Channel B. Also, Ml should be tied High 
and no equivalent to an interrupt acknowl- 
edge should be issued. 



Q: How can the Wait/Ready (W/RDY) signal 
be used by the CPU in asynchronous I/O? 

A: The W/RDY signal is most commonly used 
in Block Transfer Mode with a DMA, and 
this use is described in the Z 80 DMA 
Technical Manual. However, W/RDY may 



be directly connected to the Z80 CPU WAIT 
line m order to use the block I/O instruc- 
tions OTDR, OTIR, INDR, and INIR. In this 
case, the SIO can be used for block transfer 
reception. To do this, the SIO is configured 
to interrupt on the first character received 
only (by settings bits 4 and 3 of register 
WR1 to 01) and additiona l characters are 
sensed using the W/RDY line. The block I/O 
instructions decrement a byte counter to 
determine when I/O is complete. 



Q: Can the SYNC pin have any use in asyn- 
chronous I/O? 

A: It may be used as a general-purpose 
input. For example, by connecting it to a 
modem ring indicator, the status of that ring 
indicator can be monitored by the CPU. 



»: How can the SIO be used to transmit 
characters containing fewer than 5 bits? 

: First, set bits 6 and 5 in register WR5 to 
indicate that five or fewer bits per character 
will be transmitted. The SIO then deter- 
mines the number of bits to actually transmit 
from the data byte itself. The data byte 
should consist of zero or more Is, three 0s, 
and the data to be transmitted. Thus, begin- 
ning the data byte with 11110001 will cause 
only the last bit to be transmitted: 

Contents of data byte 
(d = arbitrary value) 

D 7 D 6 D 5 D 4 D 3 D 2 D] D 



1 


1 


1 


1 











d 


1 


1 


1 


1 











d 


d 


2 


1 


1 











d 


d 


d 


3 


1 











d 


d 


d 


d 


4 











d 


d 


d 


d 


d 


5 



*The rightmost number of bits indicated will be transmitted 

Q: Can a Break sequence be sent for a fixed 
number of character periods? 

A: Yes. Break is continuously transmitted as 
logic by setting bit 4 of register WR5. You 
can then send characters to the transmitter 
as long as the Break level is desired to per- 
sist. A Break signal, rather than the char- 
acters sent, will actually be transmitted, but 
each bit of each character sent will be 
clocked as if it were transmitted. The All 
Sent bit, bit of register RR1, is set to 1 
when the last bit of a character is clocked 
for transmission, and this may be used to 
determine when to reset bit 4 of register 
WR5 and stop the Break signal. 

Q: If a Break sequence is initiated by setting 
bit 4 of register WR5, will any character 
m the process of being transmitted be 
completed? 

A: No. Break is effective immediately when 
bit 4 of WR5 is set. The "all sent" bit in 
register RR1 should be monitored to deter- 
mine when it is safe to initiate a Break 
sequence. 
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SECTION 

6 



A Longer Example. 

In this section, we give a longer example of 
asynchronous interrupt-driven full-duplex I/O 
using the SIO. The code for this example is 
contained in Appendix A, and the basic 
routines are flow charted in Figures 7-12. 

The example includes code for initialization 
of the SIO, initialization of a receive buffer 
interrupt routine, and a transfer routine which 
causes a buffer of up to 80 characters of infor- 
mation to be transmitted on Channel A and a 
buffer of up to 80 characters of information to 
be received from Channel A. The transfer 
routine stops when either all data is received 
or an error occurs. Completion of an operation 
on a buffer for both receive and transmit is 
indicated by a carriage return character. 
Additional routines (not included in this exam- 
ple) would be needed to call the initialization 
code and initiate the transfer routine. There- 
fore, we do not present a complete example; 
that would only be possible when all details of 
a particular communication environment and 
operating system were known. 

The code begins by defining the value of the 
SIO control and data channels, followed by 
location definitions for the interrupt vector. 
There is then a series of constant definitions of 
the various fields in each register of the SIO. 
This is followed by a table-driven SIO initiali- 
zation routine called "SIO init," shown in 

Figure 7, which uses the table beginning at 

the location "SlOItable." The SIO Init routine 

initializes the SIO with exactly the same 



LOAD I REGISTER WITH 

HIGH BYTE OF INTERRUPT- 

TABLE ADDRESS 



LOAD A MEMORY LOCATION 

WITH LOW BYTE OF 
INTERRUPT TABLE ADDRESS. 



LOAD HL REGISTER WITH 
BEGINNING ADDRESS OF 
SIO INITIALIZATION TABLE 



MOVE DATA WORD FROM 

INITIALIZATION TABLE TO 

A REGISTER; INCREMENT HL. 




OUTPUT DATA WORD TO 

CONTROL PORT OF BOTH 

SIO CHANNELS 



Figure 7. Interrupt-Driven 
Initialization Routine 



SET TRANSMIT BUFFER POINTER TO BEGINNING 

OF TRANSMIT BUFFER SET RECEIVE BUFFER 

POINTER TO BEGINNING OF RECEIVE 

BUFFER. SET RECEIVE BUFFER COUNTER, 

TRANSMIT STATUS WORD, AND RECEIVE 

STATUS WORD TO ZERO. 



SAVE REGISTERS 




GET NEXT CHARACTER, 
TRANSMIT, AND INCREMENT 
TRANSMIT BUFFER POINTER 




TURN OFF 
TRANSMITTER 
INTERRUPTS 



RESTORE SAVED REGISTERS 



RETURN FROM INTERRUPT 



Figure 8. Interrupt-Driven 
Transmit Routine 



Figure 9. Transmitter Buffer 
Empty Interrupt Routine 
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A Longer parameters as the interrupt-driven example in 

Example the previous section. The table-driven version 

(Continued) is presented simply as an alternative means of 
coding this material. 

A short routine for filling the receive buffer 
with "FF" (hex) characters and buffer defini- 
tions follows the SIO Init routine. This in turn 

is followed by the transfer routine, Figure 8, 
which begins transmitting on Channel A; 
transmission and reception is thereafter 
directed by the interrupt routines. After the 
transfer routine begins output, it checks for 
various error conditions and loops until there 
is either completion or an error. 

Then the four interrupt routines follow: 
TxBEmpty, Figure 9, is called on a transmit 
buffer interrupt; it begins transmission of the 
next character in the buffer. A carriage return 
stops transmission. RecvChar, Figure 10, is 
called on a normal receive interrupt; it places 
the received character in the buffer if the buf- 
fer is not full and updates receive counters. 
The routines SpRecvChar, Figure 11, and 
ExtStatus, Figure 12, are error interrupts; they 
update information to indicate the nature of 
the error. 

The code of this example can be used in a 
situation where data is being sent to a device 
which echoes the data sent. In such a case, the 
transmit and receive buffers could be com- 
pared upon completion for line or transmission 
errors. 



SAVE REGISTERS 









_S^ rec 
<*r BUF 


EIVE ^^ 
FER ^v. 

LL ^^ 

NO 




' ' 


YES X Fl 




SET RECEIVE 
STATUS WORD 

TO 
"OVERFLOW" 




INCREMENT RECEIVE BUFFER 

COUNTER AND RECEIVE BUFFER 

POINTER STORE B REGISTER 

CONTENTS WHERE RECEIVE 

BUFFER POINTS TO 










\ 




SET RECEIVE 
STATUS WORD 

TO 
"COMPLETE" 


^^ W 
_^S^ CHARA 


CTERA ^"^ 
E RETURN^" 


"* YES ^\CARRIAG 




1 1 


NO 




'' 


RESTORE SAVED REGISTERS 



RETURN FROM INTERRUPT 



Figure 10. Receive Character 
Interrupt Routine 



SAVE REGISTERS 



STORE CONTENTS OF 
RR1 IN RECEIVE 
STATUS WORD 



RESET ERROR LATCHES 
IN SIO 



SAVE REGISTERS 



STORE CONTENTS OF RRO 
IN THE TRANSMIT 
STATUS WORD 



SEND THE RESET 

EXTERNAL/STATUS 

INTERRUPTS COMMAND 



RESTORE SAVED REGISTERS 



RESTORE SAVED REGISTERS I 



RETURN FROM INTERRUPT 



RETURN FROM INTERRUPT 



Figure 11. Special Receive Condition 
Interrupt Routine 



Figure 12. External/Status 
Interrupt Routine 



26-0003-0349 26-0003-0350 26-0003-0351 
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Appendix A 

Interrupt-Driven Code Example 



SIO Port Identifiers and System Address Bus Addresses 


WR3 Commands 

B5: EQU 


00H 












; Receive 5 bits/character 


SIO: 


EQU 


40H 




RENABL: 


EQU 


01H 


; Receiver enable 


SIOAData: 


EQU 


SIO + 1 




ENRCVR: 


EQU 


01H 


; Receiver enable 


SIOACtrl: 


EQU 


SIO + 2 




SCLINH: 


EQU 


02H 


;Sync character load inhibit 


SIOBData: 


EQU 


SIO + 3 




ADSRCH: 


EQU 


04H 


; Address search mode 


SIOBCtrl. 


EQU 


SIO + 4 




RCRCEN: 


EQU 


08H 


, Receive CRC enable 










HUNT: 


EQU 


10H 


; Enter hunt mode 










AUTOEN: 
B7: 
B6: 
B8: 


EQU 
EQU 
EQU 
EQU 


20H 
40H 
80H 
OCOH 


,Auto enables 






Table of Interrupt Vectors 


; Receive 7 bits/character 
, Receive 6 bits/character 
; Receive 8 bits/character 


The table (Int Tab) starts at 


the lowest priority vector, which 


should be ddddOOOd 






















WR4 Commands 








ORG 


ODOH 


, starts at address with low 


SYNC. 


EQU 


00H 


;Sync modes enable 








, byte = 11010000 


NOPRTY. 


EQU 


00H 


; Disable parity 


Int_Tab: 


DEFW 


TxBEmpty 


interrupt types for Channel B 


ODD- 


EQU 


00H 


,Odd parity 




DEFW 


ExtStat 




MONO- 


EQU 


00H 


,8 bit sync character 




DEFW 


RxChar 




CI. 


EQU 


00H 


,X1 clock mode 




DEFW 


SpRxCond 




PARITY: 


EQU 


01H 


, Enable parity 










EVEN: 


EQU 


02H 


;Even parity 




DEFW 


TxBEmpty 


interrupt types for Channel A 


SI: 


EQU 


04H 


, 1 stop bit/character 




DEFW 


ExtStat 




S1HALF: 


EQU 


08H 


, 1 and a half stop bits/character 




DEFW 


RxChar 




S2: 


EQU 


0CH 


,2 stop bits/character 




DEFW 


SpRxCond 




BISYNC. 


EQU 


10H 


,16 bit sync character 










SDLC. 
ESYNC. 


EQU 
EQU 


20H 
30H 


,SDLC mode 

; External sync mode 












Command Identifiers and Values 


C16. 
C32: 


EQU 
EQU 


40H 
80H 


;X16 clock mode 










;X32 clock mode 


Includes all control bytes for asynchronous and synchronous I/O. 


C64: 


EQU 


OCOH 


; X64 clock mode 


WRO Commands 






WR5 Commands 






RO. 


EQU 


00H 


,SIO register pointers 


T5. 


EQU 


00H 


, Transmit 5 bits/character 


Rl. 


EQU 


01H 




XCRCEN: 


EQU 


01H 


; Transmit CRC enable 


R2: 


EQU 


02H 




RTS. 


EQU 


02H 


,Reguest to send 


R3: 


EQU 


03H 




SELCRC: 


EQU 


04H 


, Select CRC- 16 polynomial 


R4: 


EQU 


04H 




XENABL: 


EQU 


08H 


, Transmitter enable 


R5: 


EQU 


05H 




BREAK 


EQU 


10H 


,Send break 


R6: 


EQU 


06H 




T7. 


EQU 


20H 


, Transmit 7 bits/character 


R7: 


EQU 


07H 




T6- 


EQU 


40H 


; Transmit 6 bits/character 


NC: 


EQU 


00H 


;Null Code 


T8- 


EQU 


60H 


, Transmit 8 bits/character 


SA: 


EQU 


08H 


;Send Abort (SDLC) 


DTR- 


EQU 


80H 


;Data terminal ready 


RESI: 


EQU 


10H 


, Reset Ext/Stat Int 


















CHRST: 


EQU 
EQU 


18H 
20H 


, Channel Reset 

; Enable Int On Next Rx Char 






Initialization 


EIONRC: 


SIO_Imt: 


LD 


HL, Int_Tab 




RTIP: 


EQU 


28H 


, Reset Tx Int Pending 




LD 


A,H 




ER- 


EQU 


30H 


, Error Reset 




LD 


I, A 




RFI- 


EQU 


38H 


;Return From Int 




LD 


A,L 




RRCC: 


EQU 


40H 


, Reset Rx CRC Checker 




LD 


(I_Loc),A 




RTCG. 


EQU 


80H 


, Reset Tx CRC Generator 




LD 


HL, SlOItable 




RTUEL: 


EQU 


OCOH 


; Reset Tx Under/EOM Latch 


















Init Loop 


LD 
INC 


A,(HL) 
HL 


,loop for initialization 


WR1 Commands 








CP 







WAIT: 


EQU 


00H 


,Wait function 




RET 


Z 




DRCVRI: 


EQU 


00H 


, Disable Receive interrupts 




OUT 
OUT 
IR 


(SIOACtrl), A 
(SIOBCtrl),A 
Init Loop 




EXTIE. 


EQU 


01H 


, External interrupt enable 






XMTRIE: 


EQU 


02H 


; Transmit interrupt enable 






SAVECT: 


EQU 


04H 


; Status affects vector 


SlOItable: 


DEFB 


CR 


; table for initialization 


FIRSTC. 


EQU 


08H 


,Rx interrupt on first character 




DEFB 


R4 + RESI 




PAVECT: 


EQU 


10H 


,Rx interrupt on all characters 
, (parity affects vector) 




DEFB 
DEFB 


C64 + ODD 
R3 + RESI 


+ PARITY + S2 


PDAVCT: 


EQU 


18H 


,Rx interrupt on all characters 




DEFB 


B8 + AUTOEN + ENRCVR 








, (parity doesn't affect vector) 




DEFB 


R5 + RESI 




WRONRT: 


EQU 


20H 


, Wait/Ready on receive 




DEFB 


DTR + RTS - 


f T8 + XENABL 


RDY: 


EQU 


40H 


, Ready function 




DEFB 


R2 + RESI 




WRDYEN: 


EQU 


80H 


, Wait/Ready enable 


I Loc. 


DEFS 


1 


location of int table 


WR2 Commands 








DEFB 


Rl + RESI 


, address 












DEFB 


EXTIE + XMTRIE + SAVECT + PAVECT 


IV: 


EQU 


00H 






DEFB 
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Receiver Buffer Initialization 



Receive Character Routine (see Figure 10) 



Buf_Init. LD 
LD 
LD 
LD 



Buf_l 



LD 
INC 
DJNZ 
RET 

BufLength: EQU 
XBuffer DEFS 
RBuffer. DEFS 

XBufPtr DEFS 
RBufPtr DEFS 
RBufCtr. DEFS 



A, BufLength 
B,A 

HL,RBuffer 
A,0FFH 

(HL),A 

HL 

Buf_l 



BufLength 
BufLength 

2 
2 
1 



, fill receiver buffer 
, with FF characters 
; to detect errors 

,a loop for Buf Init 



; buffer length 

,Tx buffer starting location 

,Rx buffer starting location 

,Tx pointer 
;Rx pointer 
,Rx counter 



Transmit Routine (see Figure 8) 
Initiates transmission of a buffer-full of data and terminates when 
an error is detected or a complete buffer has been received 

RxStat DEFS 1 , Receive Status Word 

TxStat DEFS 1 , Transmit Status Word 



Complete 


EQU 


1 




CR- 


EQU 


ODH 




Break 


EQU 


80H 




EOM 


EQU 


80H 




Overflow 


EQU 


OFFH 




Transfer 


LD 


HL, XBuffer 


, setup to begin Tx 




INC 


HL 






LD 


(XBufPtr), HL 






LD 


HL, RBuffer 






LD 


(RBufPtr), HL 






XOR 


A 


,A = 




LD 


(RBufCtr), A 






LD 


(TxStat), A 






LD 


(RxStat), A 






LD 


A,SIOAData 


; start Tx task 




LD 


C,A 






LD 


HL, (XBuffer) 


, first character 




LD 


A,(HL) 






OUT 


(C),A 




Tloop. 


LD 


A.(TxStat) 


, await Tx completion < 




CP 









RET 


NZ 






LD 


A, (RxStat) 






CP 


Overflow 






RET 


Z 






CP 


Complete 






RET 


Z 






IR 


NZJloop 






RET 






Transmitter Buffer Empty Routine (see Figure 9) 


TxBEmpty 


PUSH 


AF 






PUSH 


BC 






PUSH 


HL 






LD 


HL, (XBufPtr) 






LD 


A,SIOAData 






LD 


C,A 






LD 


A,(HL) 






OUTI 








CP 


CR 






IR 


NZ, TxBExit 


,last character? 




LD 


A,RTIP 


, Reset Tx Int Pending 




INC 


C 






OUT 


(C),A 


;to control port 


TxBExit 


LD 


(XBufPtr), HL 


;save pointer 




POP 


HL 






POP 


BC 






POP 


AF 






EI 








RETI 







RxChar. 


PUSH 


AF 






PUSH 


BC 






LD 


A,SIOAData 






LD 


C,A 






IN 


A,(C) 


,get character 




LD 


B,A 






LD 


A, (RBufCtr) 






CP 


BufLength 






JR 


Z,Over 






INC 


A 


;bump counter 




LD 


(RBufCtr),A 






LD 


A,B 






LD 


HL, (RBufPtr) 


,bump pointer 




LD 


(HL),A 






INC 


HL 






LD 


(RBufPtr), HL 






CP 


CR 






IR 


NZ,RxExit 






LD 


A, Complete 






LD 


(RxStat), A 






IR 


RxExit 




Over 


LD 


A,Overflow 


indicate error 




LD 


(RxStat), A 




RxExit 


POP 


BC 






POP 


AF 






EI 








RETI 







Special Receive Condition Routine (see Figure 11) 
SpRxCond: PUSH AF 



PUSH BC 



LD 

LD 

LD 

INC 

OUT 

IN 

LD 

LD 

DEC 

OUT 

DEC 

IN 

POP 
POP 
EI 
RETI 



A,SIOAData 

C,A 

A,R1 

C 

(C),A 

A,(C) 

(RxStat), A 

A,ER 

C 

(C),A 

C 

A,(C) 

BC 

AF 



,get RR1 



,save status 
; Reset Errors 



;get character 



External/Status Routine (see Figure 12) 



ExtStatus: 



PUSH 
PUSH 

LD 
LD 
IN 
LD 
LD 
OUT 

POP 
POP 
EI 
RETI 



AF 
BC 

A,SIOACtrl 

C,A 

A,(C) 

(TxStat), A 

A,RESI 

(C),A 

BC 
AF 



;get RRO 



, Reset Ext Stat Int 



END 
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Appendix B 

Read Register Bit Functions 



READ REGISTER 

| D 7 | D 6 | D 5 | D 4 | D 3 | D 2 | D 1 | d7| 



- Rx CHARACTER AVAILABLE 
-INT PENDING (CH A ONLY) 
-Tx BUFFER EMPTY 
-DCD 

-SYNC/HUNT 

-TxUNDERRUN/EOM 

- BREAK/ABORT 



READ REGISTER If 

| D 7 | D 6 | D 5 | D 4 | D 3 | D 2 | D 1 [ D | 



I FIELD BITS I FIELD BITS IN 
IN PREVIOUS SECOND PREVIOUS 
BYTE BYTE 



- PARITY ERROR 

- Rx OVERRUN ERROR 

- CRC/FRAMING ERROR 

- END OF FRAME (SDLC) 



tUsed With Special Receive Condition Mode 
READ REGISTER 2 

j D 7 j D 6 | D s | D 4 | D 3 | P 2 | P-, | D | 
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Appendix C 

Write Register Bit Functions 



WRITE REGISTER 

| D 7 | D 6 | D 5 1 D 4 J D 3 | D 2 | Pi | Dp 1 
I I I 



1 1 



REGISTER 

1 REGISTER 1 

REGISTER 2 

1 REGISTER 3 

REGISTER 4 

1 REGISTER 5 

REGISTER 6 

1 REGISTER 7 



NULL CODE 

1 SEND ABORT (SDLC) 

1 RESET EXT/STATUS INTERRUPTS 

1 1 CHANNEL RESET 

1 ENABLE INT ON NEXT Rx CHARACTER 
1 1 RESET TxINT PENDING 

1 1 ERROR RESET 

1 1 1 RETURN FROM INT (CH-A ONLY) 

NULL CODE 

RESET Rx CRC CHECKER 
RESET Tx CRC GENERATOR 
RESET Tx UNDERRUN/EOM LATCH 



WRITE REGISTER 4 

| D 7 | D 6 | D 5 | D 4 | D 3 | D 2 | D, | d7| 



SYNC MODES ENABLE 

1 1 STOP BIT/CHARACTER 

1 1'/! STOP BITS/CHARACTER 
1 1 2 STOP BITS/CHARACTER 

8 BIT SYNC CHARACTER 
16 BIT SYNC CHARACTER 
SDLC MODE (01111110 FLAG) 
EXTERNAL SYNC MODE 



X1 CLOCK MODE 

1 X16 CLOCK MODE 

X32 CLOCK MODE 

1 X64 CLOCK MODE 



WRITE REGISTER 1 

| D 7 [ D 6 | D 5 | D 4 | D 3 | D 2 1 D, | d7| 



-EXT INT ENABLE 
-Tx INT ENABLE 
-STATUS AFFECTS VECTOR 
(CH B ONLY) 



Rx INT DISABLE 

1 Rx INT ON FIRST CHARACTER 

INT ON ALL Rx CHARACTERS (PARITY AFFECTS VECTOR) 

1 INT ON ALL Rx CHARACTERS (PARITY DOES NOT AFFECT 
VECTOR) 



- WAIT /READY ON R/T 
-WAIT/READY FUNCTION 
-WAIT/READY ENABLE 



*OrOn 
Special 
Condition 



WRITE REGISTER 5 



S3 



-Tx CRC ENABLE 
- RTS 

-SDLC/CRC-16 
-Tx ENABLE 
-SEND BREAK 



Tx 5 BITS (OR LESS)/CHARACTER 

1 Tx 7 BITS/CHARACTER 

Tx 6 BITS/CHARACTER 

1 Tx 8 BITS/CHARACTER 



WRITE REGISTER 2 (CHANNEL B ONLY) 

| D 7 | D 6 | D 5 | D 4 | D 3 | D 2 [ D 1 | D | 



WRITE REGISTER 6 

| D 7 | D 6 | D 5 | D 4 | D 3 | D 2 | D, | D | 



-SYNC BIT 
-SYNC BIT1 
-SYNC BIT 2 I 
-SYNC BIT 3 
-SYNC BIT 4 
-SYNC BIT 5 
-SYNC BIT 6 
-SYNC BIT 7 j 



*Also SDLC Address Field 



WRITE REGISTER I 



D 7 D, D s D 4 D, D 2 D, Do 



Rx 5 BITS/CHARACTER 

1 Rx 7 BITS/CHARACTER 

Rx 6 BITS/CHARACTER 

1 Rx 8 BITS/CHARACTER 



-Rx ENABLE 

-SYNC CHARACTER LOAD INHIBIT 

-ADDRESS SEARCH MODE (SDLC) 

-RxCRC ENABLE 

-ENTER HUNT PHASE 

-AUTO ENABLES 



WRITE REGISTER 7 

| D 7 | D 6 | D 5 I D 4 I D 3 | D 2 | D, I d7| 



*For SDLC It Must Be Programmed 
to 01 1 1 1 1 10 ' For Flag Recognition 



-SYNC BIT 8 
-SYNC BIT 9 
-SYNC BIT 10 I 
-SYNC BIT 11 
-SYNC BIT 12 | 
-SYNC BIT 13 
-SYNC BIT 14 
-SYNC BIT 15 J 
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Using the Z80 SK> With SDLC 



Zilog 



AppBcation Brief 



March 1981 



INTRODUCTION This application brief describes the use of 
theZ80SIO with the increasingly popular 
Synchronous Data Link Control (SDLC) com- 
munications protocol, A general description 
of the SDLC protocol and Implementation of 
the protocol using the SIO are discussed. 
Descriptions for transmit and receive opera- 
tions are given for use with simple contol 
frame sequences. 



The reader should be familiar with hardware 
aspects of the SIO such as Interfacing to the 
CPU and a modem. A more detailed description 
of the SDLC protocol is given In the IBM 
publication Synchronous Data Link Control 
General Information (document # GA27-3093-2). 
A description of the Z80 SIO can be found in 
the Zilog Data Book (document # 00-2034-A). 



DESCRIPTION Data communication today requires a communi- 
cation protocol that can transfer data 
quickly and reliably. One such protocol, 
Synchronous Data Link Control (SDLC), is the 
link control used by the IBM Systems Network 
Architecture (SNA) communication package. 
SDLC is actually a subset of the Interna- 
tional Standards Organization (ISO) link 
control called High Level Data Link Control 
(HDLC), which Is used for international data 
communication. 



SDLC is a Bit-Oriented Protocol (BOP). It 
differs from Byte-Control Protocols (BCPs), 
such as bisync, in having a few bit patterns 
for control functions instead of several 
special character sequences. The attributes 
of the SDLC protocol are position dependent 
rather than character dependent, so control 
is determined by the location of the byte as 
well as by the bit pattern. 



A character in SDLC is sent as an octet, a 
group of eight bits. Several octets combine 
to form a message frame In such a way that 
each octet belongs to a particular field. 
Each message frame consists of an opening 
flag, address, control, Information, Frame 
Check Sequence (FCS), and closing flag 
fields. The flag field contains a unique 
binary pattern, 01111110, which indicates the 
beginning and end of a message frame. This 
pattern simplifies the hardware Interface in 
receiving devices so that multiple devices 
connected to a common link do not conflict 
with one another. The receiving devices 
respond only after a valid flag character has 
been detected. Once communication is esta- 



blished for a particular device, the other 
devices Ignore the message until the next 
flag character Is detected. 

The address field contains one or more octets 
that are used to select a particular station 
on the data link. An address of all Is is a 
global address code that selects all the 
devices on the link. When a primary station 
sends a frame, the address field Is used to 
select a secondary station. When a secondary 
station sends a message to the primary sta- 
tion, the address field contains the secon- 
dary station address, i.e., the source of the 
message. 

The control field follows the address field 
and contains Information about the type of 
frame being sent. The control field consists 
of one octet and Is always present. 

The Information field consists of zero or 
more 8-blt octets and contains any actual 
data transferred. However, because of the 
limitations of the error-checking algorithm 
used In the frame-check sequence, maximum 
recommended block size is approximately 4096 
octets. 

The Frame Check Sequence (FCS) follows the 
information field or the control field, de- 
pending on the type of message frame sent. 
The FCS is a 16-blt Cyclic Redundancy Code 
(CRC) of the bits in the address, control, 
and Information fields. The FCS is based on 
the CRC-CCITT code, which uses the polynomial 
(X 16 +X 12 +X 5 +1). The Z80 SIO contains the 
circuitry necessary to generate and check the 
FCS field. 
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Zero insertion/deletion is a feature of SDLC 
that allows any data pattern to be sent. Zero 
Insertion occurs when five consecutive 1s In 
the data pattern are transmitted. After the 
fifth 1, a is inserted before the next bit 
is sent. The data is not affected in any way 
except that there is an extra in the data 
stream. The receiver counts the 1s and de- 
letes the following the five consecutive 
1s, thus restoring the original data pattern. 
Zero insertion and deletion is necessary 
because of the hardware constraint of search- 
ing for a flag character or abort sequence. 
Six 1s preceded and followed by a indicate 
a flag character. Seven to 14 Is signify an 
abort, while an idle line (inactive) Is 
indicated by 15 or more 1s. Under these 
three conditions, zero insertion/deletion Is 
inhibited. Figure 2 illustrates the various 
I ine conditions. 



SDLC protocol differs from other synchronous 
protocols with respect to frame timing. In 
bisync, for example, a host computer might 
interrupt transmission temporarily by sending 
sync characters instead of data. This sus- 
pended condition could continue as long as 
the receiver does not time out. With SDLC, 
however, it is illegal to send flags in the 
middle of a frame to idle the line. Such an 
occurrence causes an error condition and 
disrupts orderly operation. Therefore, the 
transmitting- device must send a complete 
frame without interruption. If a message 
cannot be completed, the primary station 
sends an abort and resumes message trans- 
mission later. These conditions are discussed 
later in the Programming section of this 
brief. 



-*-Zero Insertion/Deletion and CRC Accumu I at ion - 



01111110 



One 
-bit character 



One 
8-bit character 



Zero or more 
8-bit characters 



16-bit 
CRC-CCITT 



01111110 



Flag 
(Beginning 
of message 

frame) 



Address 



Control 



Information 



FCS 



Flag 

(End of 

message 

frame) 



Figure 1. A Typical SDLC Message Frame Format 



Flag 



01111110 



Address 



Control 



10110000 



011111011 



Address = 10110000 
Control = 01111111 
a) Zero Insertion 



ft- 



Flag 



01111110 



Actual Data Stream 



Zero insertion 



XXXX1 11111101111110... 



Abort Flag 
b) Abort Condition 



XXXX 111111111111111. 

Idle 
c) Idle Condition 



Figure 2. Bit Patterns for Various Line Conditions 
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PROGRAMMING Implementation of the SDLC protocol with the 
THE SIO Z80 SIO is simplified by the design of the 
SIO. This section discusses four areas of 
SIO programming: Initialization, transmit 
operation, receive operation, and exception 
condition processing. 

Initialization defines the basic mode of 
operation for the SIO, Table 1 shows the 
sequence of steps used to initialize the SIO, 
along with the necessary parameters. Since 
vectored interrupts are used, the SIO is pro- 
grammed with the status affects vector (SAV) 
bit (WR1, bit 2) set. 

Other function bits that can be included are 
the external interrupt enable bit (WR1, bit 
0), which results in an interrupt for each 
DCD or CTS change, T x underrun or abort 
change; address search bit (WR3, bit 2), 
which when set, prevents the SIO from res- 
ponding to data received unless the address 
byte matches the contents of WR6 or the 
global (FFH) address; auto enable bit (WR3, 
bit 5), which causes the inactive CTS level 
to disable the transmitter and the inactive 
DCD level to disable the receiver; and DTR 
(WR5, bit 7) and RTS (WR5, bit 1), which can 
be used to control a modem or other such 
device. 



Once the SIO is initialized and the trans- 
mitter Is enabled, It sends flag characters 
continuously until a message begins trans- 
mission. These flag characters consist of 
the full 8-bit pattern. Although the SIO can 
receive flag characters with shared 0s 
(0111111011111101111110...), it can only 
transmit flag characters without shared 0s 
(011111100111111001111110...). 



Table 1. SIO Initialization Sequence 



ster 


Data 


Function 





00011000 


Channel reset 


2 


(Vector) 


Interrupt vector 
lower eight bits 
(channel B only) 


4 


00100000 


SDLC mode 


1 


00011111 


Interrupt control 


6 


(Address) 


R x address field 


7 


01111110 


Flag field 


5 


11101011 


T x character length, 
enable, CRC enable 
RTS and DTR 


3 


11001001 


R x character length, 
enable, and CRC 
enable 



TRANSMIT After the SIO has been initialized and 
OPERATION enabled, it can begin sending SDLC frames by 
software activation of the transmitter. 
Activating the transmitter includes resetting 
the transmitter inactive semaphore (a program 
indicator), resetting the T x CRC accumula- 



tion, sending a character to the SIO, and re- 
setting the T x underrun/EOM latch in the SIO. 
Figure 3 shows the sequence for transmitting 
a typical control message frame using inter- 
rupts. 

SDLC T Y 



Control Message Frame 



XXXXXX011 11110 

I 

Activate T Y 



Address 


Control 


CRC-1 


CRC-2 











01111110... 



TBE* 



TBE ESC" 1 " 



TBE^- 



Control 
to SIO 



Check error conditions; 
Update semaphores 



Address to SIO, 
Reset T x 
Underrun/EOM latch 



Set MC semaphore 
(no data to SIO), 
Reset TBE pending 



-Interrupt 
Condition 



(no data to SIO), 
Start response timer, 
Reset TBE pending, 
Set T x inactive 
Reset MC semaphore 



* - Transmit Buffer Empty 
+ = Externa I /Status Change 



Figure 3. A Typical Transmit Control Frame Sequence 
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When the SIO is loaded with the first data 
character (address byte), it stores the 
character in the T x buffer until the current 
flag character has completed shifting. After 
the address byte is transferred into the 
shift register, a Transmit Buffer Empty (TBE) 
interrupt occurs. The program then loads the 
control character into the SIO and continues 
processing. The next TBE interrupt is Ig- 
nored by the program (and no further data is 
sent to the SIO), but a Reset T x Interrupt 
Pending command is issued to the SIO to clear 
the TBE interrupt condition. Also, the pro- 
gram Message completed (MC) semaphore is set 
so that appropriate action can be taken when 
the next TBE interrupt occurs. 

When the last data character (the control 
byte) has been shifted out of the SIO, the T x 
underrun/EOM latch is set because the SIO 
buffer was not loaded with a character on the 
previous TBE interrupt. As a result, an 
External/ Status Change (ESC) interrupt 
occurs and the SIO begins transmitting the 
FCS bytes automatically. In the ESC inter- 



rupt service routine, the program checks for 
other condition changes including CTS, DCD, 
and abort, and passes the status on to the 
program at the next-higher level. 

After the FCS bytes have been shifted out, 
the SIO generates a TBE interrupt to indicate 
that a flag character is being transmitted. 
The TBE interrupt service routine interprets 
the MC semaphore and determines that the 
frame has completed transmission. The pro- 
gram then clears the MC semaphore, sets the 
Transmitter Inactive semaphore, starts a 
timer for a response from the receiving de- 
vice, and clears the TBE interrupt condition. 
At this point, transmission of an SDLC mes- 
sage frame is complete and another message 
frame may be sent. 

If the transmitter is to be turned off, the 
program must allow at least a two-character 
time delay before disabling the transmitter. 
This can be accomplished by connecting the 
SIO T x clock line to the input of a counter 
and having the counter interrupt the CPU when 
the bit count expires. 



RECEIVE The SDLC receive sequence is slightly less 
OPERATION complex than the transmit sequence. To begin, 
the SIO enters Hunt mode when any of three 
conditions occurs: receive enable, abort 
detect, or a software command. In Hunt mode 
the SIO searches for flag characters, and 
when it detects a flag, the SIO generates an 
ESC interrupt. This interrupt can be used to 
signal line activation or the end of an abort 
condition, depending upon the previous re- 
ceive condition. For example, when the SIO 
has been initialized, the receive circuitry 



is enabled and immediately begins searching 
for flag characters (Hunt mode operation). 
When the first flag is detected, the SIO 
exits from Hunt mode, which results in an ESC 
interrupt, and the SIO begins searching for 
the address field. If the SIO is programmed 
for Address Search mode and an address is 
received that does not match the programmed 
address byte in the SIO, the SIO does nothing 
until the next flag is found, after which the 
SIO again searches for an address match. 



SDLC RX 



control message frame - 



...01111110 



Address 



Control 



CRC-1 



CRC-2 



01111110 



RCA + 



S 



Continuous 
flags 



RCA RCA SRC ++ RCA Interrupt 

I Condition 



Store data Store Store Set semaphores (If character 

(if desired) data data Check errors; is not discarded 

Error Reset; by SRC routine, 

Discard this RCA interrupt 

Character* occurs. ) 



NOTES 

* The SRC routine normally reads the data character to clear the 
SIO buffer. This should be done after the program issues an Error 
Reset command. 

+ RCA = Receive Character Available 

++ SRC = Special Receive Condition (higher priority than RCA) 

Figure 4. A Typical Receive Control Frame Sequence 
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If the address field matches the address byte 
programmed into the SIO, the SIO generates a 
Receive Character Aval I able (RCA) Interrupt 
when the address byte Is ready to be trans- 
ferred from the SIO to the CPU. If the SIO 
Is programmed to Interrupt on all receive 
characters, It generates an RCA Interrupt for 
each character received thereafter. It 
should be noted that the SIO generates the 
RCA Interrupt when a character reaches the 
top of the receive FIFO rather than when a 
character Is transferred from the shift 
register to the FIFO. This means that If the 
FIFO Is full of data, each character gener- 
ates a separate RCA Interrupt. This results 
in a more consistent software routine that 
does not need to check the receive FIFO, 
provided there Is enough time between char- 
acter transfers to allow the routine to com- 
plete the processing for each character. 

After the last FCS byte of a frame Is re- 
ceived and processed, the SIO generates a 
Special Receive Condition (SRC) Interrupt, 
which Is of higher priority than the RCA 
Interrupt. In the SRC service routine, RR1 
Is read to determine the cause of the Inter- 
rupt and the appropriate program semaphores 
are updated. Normal completion results In no 
FCS or overrun errors and the End-of-Frame 

Wake; 

Clear T x Inactive semaphore 
Reset T x CRC 
Data to SIO 

(Address field byte) 
Reset T x Underrun/EOM latch 



bit Is set. Upon completion of the SRC In- 
terrupt service routine, the program Issues 
an Error Reset command to the SIO and reads 
the data port to discard the received data. 
If the data Is not read and discarded, an RCA 
Interrupt occurs. Now, a complete message 
frame and the first FCS byte are In the re- 
ceive buffer. 

Figure 4 shows the sequence for a typical 
control frame received by the SIO. If the 
address field byte is to be discarded, a 
program semaphore should initially be set to 
signal this to the RCA routine. After the 
address field has been received, the sema- 
phore Is cleared and reception continues 
normally. Note that upon completion of a 
frame, an RCA Interrupt Is generated for the 
first FCS byte and an SRC Interrupt Is gen- 
erated for the last CRC byte. 

Table 2 lists the contents of the Interrupt 
service routines used with the SIO. The wake 
routine Is not an Interrupt service routine 
but Is a routine called by the program on the 
next higher level to begin frame transmis- 
sion. Once the wake routine Is called, the 
program on the next higher level monitors the 
T x active semaphore to determine when the 
current frame completes transmission and the 
next frame transmission can begin. 

Externa I /Status Change (ESC) ; 
Clear DCD, CTS, abort semaphores 
If (abort) 

Set abort semaphore 
Else If (DCD change) 

Set DCD semaphore 
Else If (CTS change) 

Set CTS semaphore 



Transmit Buffer Empty (TBE) ; 
If (MC cleared) 

If (buffer not empty) 

Data to SIO 
Else, 

Set MC semaphore 
Reset TBE condition 
Else, 

Clear MC 
Set T x inactive 
Reset TBE condition 
Start Response timer 



Receive Character Available (RCA); 
If (EOF) 

Read and discard data 
Else, 

Store data 



Special Receive Condition (SRC); 
Read SIO RR1 
If (EOF) 

Set EOF semaphore 
Else If (CRC error) 

Set R x CRC error semaphore 
Else If (R x overrun) 

Set R x overrun semaphore 
Issue Error Reset 
Read data & discard 



Table 2. SIO SDLC Interrupt Service Routines 
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Most of the exception conditions encountered 
in the SDLC protocol have been discussed in 
the previous sections. They include abort 
detect and DCD or CTS change. This section 
further describes some of the more unusual 
conditions, 

DCD and CTS Change* The program handles DCD 
and CTS change by updating its semaphores 
each time an ESC interrupt occurs. In this 
manner, the program on the next higher level 
monitors the semaphores and determines a 
course of action based on what these sema- 
phores indicate. 

Abort and Idle Line Detect. Abort and idle 
line detect are a bit more complicated, since 
they result in similar interrupt operations. 
An abort occurs during a valid message frame. 
If the abort time is greater than 14 bits, an 
idle line is detected. This detection can be 



done by activating a timer when the ESC in- 
terrupt that signals a marking line occurs. 
If another ESC interrupt occurs before the 
timer times out, the line is in an abort 
condition. If the timer times out before 
another ESC interrupt occurs, then the line 
is idle and the program can pursue an appro- 
priate course of action, A possible mech- 
anism for implementing the timer function is 
to use a programmable counter that is tied to 
the receive clock line to count bits. The 
counter is programmed for eight clock tran- 
sitions and is started as soon as the SIO 
interrupts the CPU with an abort condition. 
Only eight clock transitions need to be 
counted because by the time the SIO generates 
the ESC interrupt, at least seven 1s have 
already passed. Figure 6 shows the abort/ 
idle line timing and the interrupts resulting 
from the line changes. 



abort, "window" 

I 1 

...1111111111111111 0111111001111110. 



ESC 



interrupt, 

abort bit set 

i 
i 
I 
I 

I 



counter/timer ESC interrupt, hunt bit cleared 
expires SIO back in sync, 

I ine active. 



If another ESC interrupt occurs within 
the abort window and the abort bit is 
cleared, the program has detected an 
abort. Otherwise, when the counter/ 
timer expires, an idle line has been 
detected. 

Figure 6. Abort/ 1 die Line Conditions 



CONCLUSION This brief describes implementation of the 

SDLC protocol using the SIO in an interrupt- 
driven environment. Descriptions for trans- 
mit and receive operations are given for use 
with simple control frame sequences. For 
frames that transfer data, the sequences are 
similar except for transmit, where a data 
character is sent to the SIO for a TBE in- 
terrupt. For receive, multiple RCA inter- 



rupts occur for each data byte received. 

The Z80 SIO enhances system performance by 
minimizing CPU intervention during data 
transfers using the SDLC protocol. Perfor- 
mance can be improved further by using the 
Z80 DMA with the SIO, resulting in an effi- 
cient system configuration that reduces CPU 
interaction to a minimum. 



APPENDIX Following is the listing of a simple SIO test 

progam that uses the SDLC protocol. This 
program uses vectored interrupts to send a 
short SDLC control frame consisting of Ad- 
dress 9EH, Control 19H, and Data 81H. The 
response timer times the response of the 
receiving station after a message has been 



sent. If the response timer expires, the 
program on the next higher level normally 
retransmits the message frame (if the re- 
transmit count has not yet expired). This 
program transmits continuously until the 
processor is reset or interrupted by an ex- 
ternal source. 



LOC 



TEST SDLC 
OBJ CODE M STMT SOURCE STATEMENT 



ASM 5 9 



, C03 



SIO SDLC TEST PROGRAM 
01-21-81 /MDP 



INITIAL CREATION 
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LOG 



TEST. SDLC 
OBJ CODE M STMT SOURCE STATEMENT 



ASM 5 9 



5 




THIS PROGRAM SENDS ADDRESS 9EH, CONTROL 19H> 


6 




AND DATA 81H CONTINUOUSLY USING THE Z80 VECTO 


7 




INTERRUPT MODE. 


THE SIO 


IS INITIALIZED TO USE 


8 




SDLC WITH THE BAUD RATE 


SLOCK SUPPLIED BY 


9 




HARDWARE INTERNAL TO THE 


SYSTEM. 


10 












11 


, 


EQUATES 






12 












13 


ADDRESS 




EQU 


9EH 


, ADDRESS FIELD 


14 


CTRL: 


EQU 


19H 




CONTROL FIELD 


15 


DATA: 


EQU 


81H 




, INFORMATION FIELD 


16 


MSGLEN- 


EQU 


1 




, MESSAGE LENGTH 


17 


RAM: 


EQU 


2000H 




, RAM ORIGIN 


18 


RAMSIZ: 


EQU 


1000H 




RAM SIZE 


19 


SICCA: 


EQU 







, SIO PORT A DATA 


20 


SIOCA: 


EQU 


SIODA+1 




, SIO PORT A CTRL 


21 


SIODB: 


EQU 


SIODA+2 




SIO PORT B DATA 


22 


SIOCB- 


EQU 


SIODB+1 




SIO PORT B CTRL 


23 


CIOC: 


EQU 


8 




CIO PORT C 


24 


CIGB: 


EQU 


CIOC+1 




CIO PORT B 


25 


CIGA: 


EQU 


CIOC +2 




CIO PORT A 


26 


CIOCTL: 


EQU 


CIOC +3 




CIO CTRL PORT 


27 


BAUD: 


EQU 


9600 




ASYNC BAUD RATE 


28 


RATE: 


EQU 


BAUD/ 100 




29 


CIOCNT- 


EQU 


9216/RATE 




30 


LITE: 


EQU 


OEOH 




LIGHT PORT 


31 
32 
33 


RSPCNT: 


EQU 


100 




RESPONSE TIMER VALUE 


; 


SIO PARAMETERS 






34 












35 


SIOWRO: 


EQU 









36 




CHRES: 


EQU 


18H 


CH. RESET CMD 


37 




ESCRES 


EQU 


10H 


ESC RESET CMD 


38 




TBERES 


EQU 


28H 


TBE RESET CMD 


39 




RETIA: 


EQU 


38H 


RETI CH. A 


40 




ENINRX 


EQU 


20H 


ENAB. INT. NEXT RX 


41 




SRCRES 


EQU 


30H 


SRC RESET CMD 


42 




RCRCRE 


EQU 


40H 


RX CRC RESET CMD 


43 




TCRCRE 


EQU 


80H 


TX CRC RESET CMD 


44 




EOMRES 


EQU 


OCOH 


EOM RESET CMD 


45 












46 


SI0WR1: 


EQU 


1 






47 




WREN: 


EQU 


80H 


WAIT/RDY ENABLE 


48 




RDY: 


EQU 


40H 


READY FUNCT. 


49 




WRONR: 


EQU 


20H 


WAIT/RDY ON RX 


50 




RXIFC: 


EQU 


8 


RX INT FIRST CHAR 


51 




RXIAP: 


EQU 


10H 


RX INT ALL + PARITY 


52 




RXIA: 


EQU 


18H 


RX INT. ALL 


53 




SIOSAV 


EQU 


4 


STATUS AFFECTS VECT 


54 










(CH. B ONLY) 


55 




TXI: 


EQU 


2 


TX INT. ENABLE 


56 




EXTI 


EQU 


1 


EXT INT. ENABLE 


57 












58 


SIGWR2: 


EQU 


2 




(CH B ONLY) 


59 












60 


SI0WR3: 


EQU 


3 






61 




RX8. 


EQU 


OCOH 


RX 8 BITS 


62 




RX6: 


EQU 


80H 


RX 6 BITS 


63 




RX7: 


EQU 


40H 


RX 7 BITS 


64 




RX5: 


EQU 





RX 5 BITS 


65 




AUTOEN 


EQU 


20H 


AUTO ENABLES 


66 




HUNT: 


EQU 


10H 


HUNT MODE 


67 




RXCRC: 


EQU 


8 


RX CRC ENABLE 


68 




ADSRCH 


EQU 


4 


ADDR SEARCH 


69 




SYNINH 


EQU 


2 


SYNC LOAD INHIBIT 


70 




RXEN: 


EQU 


1 


RX ENABLE 


71 












72 


SI0WR4: 


EQU 


4 






73 




X64 


EQU 


OCOH 


64X CLOCK 


74 




X32: 


EQU 


80H 


32X CLOCK 


75 




X16: 


EQU 


40H 


16X CLOCK 


76 




XI: 


EQU 





IX CLOCK 
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TEST. SDLC 








LOC 


OBJ CODE M STMT 


SOURCE 


STATEMENT 






ASM 5 9 






77 




EXTSYN: 


EQU 


30H 


; EXT SYNC ENABLE 






78 




SDLC: 


EQU 


20H 


} SDLC MODE 






79 




SYN16: 


EQU 


10H 


; 16 BIT SYNC 






80 




SYN8: 


EQU 





;8 BIT SYNC 






81 




ST0P2: 


EQU 


OCH 


; 2 STOP BITS 






82 




STOP 15: 


EQU 


8 


; 1. 5 STOP BITS 






83 




ST0P1: 


EQU 


4 


i 1 STOP BIT 






84 




SYNCEN: 


EQU 





; SYNC ENABLE 






85 




EVEN: 


EQU 


2 


, EVEN PARITY 






86 




PARITY: 


EQU 


1 


PARITY ENABLE 






87 
















88 


SI0WR5 


EQU 


5 










89 




DTR 




EQU 


80H 


AC! IVATE DTR 






90 




TX8 




EQU 


60H 


TX 8 BITS 






91 




TX6 




EQU 


40H 


TX 6 BITS 






92 




TX7 




EQU 


20H 


TX 7 BITS 






93 




TX5 




EQU 





TX 5 BITS 






94 




BREAK: 


EQU 


10H 


TX BREAK 






95 




TXEN: 


EQU 


8 


TX ENABLE 






96 




CRC16: 


EQU 


4 


CRC-16 MODE 






97 




RTS: 


EQU 


2 


ACTIVATE RTS 






98 




TXCRC: 


EQU 


1 


TX CRC ENABLE 






99 
















100 


SIC3WR6 


EQU 


6 




LOW SYNC OR ADDR 






101 
















102 


SICJWR7 


EQU 


7 




HIGH SYNC OR FLAG 






103 
















104 




SIOFLG 


» FLAGS 


FOR SIO STATUS 






105 
















106 




BIT 


SET CONDITION 








107 
















108 







TX ACTIVE 








109 




1 


MESSAGE COMPLETE 








110 




2 


CTS ACTIVE 








111 




3 


DCD ACTIVE 








112 




4 


ABORT DETECT 

RX OVERRUN ERROR 








113 




5 








114 




6 


RX CRC 


ERROR 








115 




7 


RX END 


OF FRAME 








116 


*E 














117 
















118 


; , 


*** MAIN PROGRAM *** 








119 












OOOO 




120 




ORG 









0000 


C32000 


121 
122 




JP 


BEGIN 




GO MAIN PROGRAM 






123 


i 


INTERRUPT VECTORS 








124 


; 


(MUST START ON 


EVEN BOUNDARY) 






125 












ooio 




126 




ORG 


$. AND. OFFFOH. OR. 


10H 






127 


INTVEC 














128 


SIGVEC 










0010 


9C00 


129 




DEFW 


CHBTBE 






0012 


D100 


130 




DEFW 


CHBESC 






0014 


0101 


131 




DEFW 


CHBRCA 






0016 


0F01 


132 




DEFW 


CHBSRC 






0018 


3B01 


133 




DEFW 


CHATBE 






001A 


4301 


134 




DEFW 


CHAESC 






001C 


4B01 


135 




DEFW 


CHARCA 






001E 


5101 


136 
137 
138 


BEGIN: 


DEFW 


CHASRC 






0020 


314020 


139 




LD 


SP, STAK 


INIT SP 


0023 


ED5E 


140 




IM 


2 




VECTOR INTERRUPT MODE 


0025 


3E00 


141 




LD 


A, INTVEC/256 


UPPER VECTOR BYTE 


0027 


ED47 


142 




LD 


I, A 






0029 


214520 


143 




LD 


HL, BUFFER 




002C 


369E 


144 




LD 


(HL), ADDRESS 


STORE ADDRESS 


002E 


23 


145 




INC 


HL 






002F 


3619 


146 




LD 


<HL),CTRL 


STORE CTRL BYTE 


0031 


23 


147 




INC 


HL 






0032 


3681 


148 




LD 


(HL), DATA 


STORE DATA BYTE 


0034 


CD4C00 


149 




CALL 


INIT 




INIT DEVICES 
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TEST. SDLC 








LOC 


OBJ CODE M STMT 


SOURCE 


STATEMENT 




ASM 5. 9 




0037 


218720 


150 




LD 


HL, RBUF 


; SETUP READ BUFFER 




003A 


228520 


151 
152 


LOOP: 


LD 


(RBPTR),HL 






003D 


213D00 


153 




LD 


HL, LOOP 


i SETUP STACK FOR RETURN 




0040 


E5 


154 




PUSH 


HL 






0041 


CD7D00 


155 
156 


L00P1: 


CALL 


WAKE 


; WAKE TX 




0044 


3A4020 


157 




LD 


A, (SIOFLO) 


; CHECK TX ACTIVE FLAG 




0047 


CB47 


158 




BIT 


0, A 






0049 


20F9 


159 




JR 


NZ,L00P1 


;LOOP IF TX ACTIVE 




004B 


C9 


160 
161 
162 
163 


INIT: 
SIOINI 


RET 








00 4C 


217001 


164 




LD 


HL, SIOTA 


; INIT CH A 




004F 


0E01 


165 




LD 


C, SIOCA 






0051 


060A 


166 




LD 


3, SIOEA-SIOTA 






0053 


EDB3 


167 




OTIR 








0055 


217A01 


168 




LD 


HL,SIOTB 


; INIT CH B 




0058 


0E03 


169 




LD 


C, SIOCB 






005A 


0610 


170 




LD 


B, SIOEB-SIOTB 






00 5C 


EDB3 


171 




OTIR 








005E 


3E00 


172 




LD 


A, 


; CLEAR FLAG BYTE 




0060 


324020 


173 
174 


CIOINI 


LD 


(SIOFLO), A 






0063 


DBOB 


175 




IN 


A, (CIOCTL) 


i INSURE STATE 




0065 


AF 


176 




XOR 


A 


i POINT TO REG 




0066 


D30B 


177 




OUT 


(CIOCTL), A 






0068 


DBOB 


178 




IN 


A, (CIOCTL) 


, CLEAR RESET OR STATE 




006A 


AF 


179 




XOR 


A 






006B 


D30B 


180 




OUT 


(CIOCTL), A 


; POINT TO REG 




006D 


3C 


181 




INC 


A 


; WRITE RESET 




006E 


D30B 


182 




OUT 


(CIOCTL), A 






0070 


AF 


183 




XOR 


A 


; CLEAR RESET COND 




0071 


D30B 


184 




OUT 


(CIOCTL), A 






0073 


218A01 


185 




LD 


HL, CLST 


i INIT CIO 




0076 


060E 


186 




LD 


B, CEND-CLST 






0078 


OEOB 


187 




LD 


C, CIOCTL 






007A 


EDB3 


188 




OTIR 








007C 


C9 


189 
190 
191 


WAKE: 


RET 








007D 


3A4020 


192 




LD 


A, (SIOFLG) 


; SET ACTIVE FLAG 




0080 


CBC7 


193 




SET 


0, A 






0082 


324020 


194 




LD 


(SIOFLG), A 






0085 


214520 


195 




LD 


HL, BUFFER 


SET BUFFER PTR 




0088 


224320 


196 




LD 


(BUFPTR),HL 






008B 


3E03 


197 




LD 


A, 2+MSGLEN 


SET BYTE COUNT 




008D 


324120 


198 




LD 


(BYTES), A 






0090 


3E80 


199 




LD 


A, TCRCRE 


CLEAR TX CRC 




0092 


D303 


200 




OUT 


(SIOCB), A 






0094 


CD9C00 


201 




CALL 


CHBTBE 


START TRANSMIT 




0097 


3EC0 


202 




LD 


A, EOMRES 


RESET EOM LATCH 




0099 


D303 


203 




OUT 


(SIOCB), A 






009B 


C9 


204 
205 
206 


*E 


RET 












207 


; , 


INTERRUPT SERVICE ROUTINES 








208 
















209 


CHBTBE 










009C 


CD5901 


210 




CALL 


SAVE 


CH B IX BUFFER EMPTY 




009F 


214020 


211 




LD 


HL, SIOFLG 


POINT TO FLAG BYTE 




00A2 


CB4E 


212 




BIT 


1, (HL) 


CHECK MC FLAG 




00A4 


201D 


213 




JR 


NZ,CHBTB2 


BRANCH IF MESSAGE CUMPLE 




TE 
















00A6 


3A4120 


214 




LD 


A, (BYTES) 


CHECK BYTE COUNT 




00A9 


B7 


215 




OR 


A 






OOAA 


280F 


216 




JR 


Z,CHBTB1 


BRANCH IF DATA DONE 




OOAC 


3D 


217 




DEC 


A 






OOAD 


324120 


218 




LD 


(BYTES), A 






OOBO 


2A4320 


219 




LD 


HL, (BUFPTR) 






00B3 


7E 


220 




LD 


A, (HL) 






00B4 


D302 


221 




OUT 


(SIODB), A 
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TEST SDLC 




L.OC 


OBJ CODE 


M STMT SOURCE STATEMENT 




00B6 


23 


222 




INC 


HL 


00B7 


224320 


223 




LD 


(BUFPTR),HL 


OOBA 


C9 


224 
225 


CHBTB1: 


RET 




OOBB 


CBCE 


226 




SET 


1, (HL) 


OOBD 


3EC0 


227 




LD 


A, EOMRES 


OOBF 


D303 


228 




OUT 


(SIOCB), A 


OOC1 


1809 


229 
230 


CHBTB2: 


JR 


CHBTB3 


00C3 


CB8E 


231 




RES 


1, (HL) 


OOC5 


CB86 


232 




RES 


0, (HL) 


00C7 


3E64 


233 




LD 


A, RSPCNT 


00C9 


324220 


234 
235 


CHBTB3: 


LD 


(RSPTMR), A 


OOCC 


3E28 


236 




LD 


A, TBERES 


OOCE 


D303 


237 




OUT 


(SIOCB), A 


OODO 


C9 


238 

239. 

240 


CHBESC: 


RET 




OOD1 


CD5901 


241 




CALL 


SAVE 


00D4 


214020 


242 




LD 


HL,SIOFLG 


00D7 


CB96 


243 




RES 


2, (HL) 


00D9 


CB9E 


244 




RES 


3, (HL) 


OODB 


CBA6 


245 




RES 


4, (HL) 


OODD 


DB03 


246 




IN 


A, (SIOCB) 


OODF 


47 


247 




LD 


B, A 


OOEO 


CB58 


248 




BIT 


3, B 


00E2 


C4FB00 


249 




CALL 


NZ, SETDCD 


OOE5 


CB68 


250 




BIT 


5, B 


00E7 


C4FE00 


251 




CALL 


NZ, SETCTS 


OOEA 


CB78- 


252 




BIT 


7, B 


OOEC 


C4F800 


253 




CALL 


NZ, SETABT 


OOEF 


CB4E 


254 




BIT 


1, (HL) 


OOF1 


2800 


255 
256 


CHBES1: 


JR 


Z, CHBES1 


00F3 


3E10 


257 




LD 


A, ESCRES 


OOFS 


D303 


258 




OUT 


(SIOCB), A 


OOF 7 


C9 


259 
260 


SETABT: 


RET 




00F8 


CBE6 


261 




SET 


4, (HL) 


OOFA 


C9 


262 
263 


SETDCD: 


RET 




OOFB 


CBDE 


264 




SET 


3, (HL) 


OOFD 


C9 


265 
266 


SETCTS- 


RET 




OOFE 


CBD6 


267 




SET 


2, (HL) 


OlOO 


C9 


268 
269 
270 


CHBRCA: 


RET 




0101 


CD5901 


271 




CALL 


SAVE 


0104 


DB02 


272 




IN 


A, (SIODB) 


0106 


2A8520 


273 




LD 


HL, (RBPTR) 


0109 


77 


274 




LD 


(HL), A 


010A 


23 


275 




INC 


HL 


010B 


228520 


276 




LD 


(RBPTR), HL 


010E 


C9 


277 
278 
279 


CHBSRC. 


RET 




010F 


CD5901 


280 




CALL 


SAVE 


0112 


3E01 


281 




LD 


A, 1 


0114 


D303 


282 




OUT 


(SIOCB), A 


0il6 


DB03 


283 




IN 


A, (SIOCB) 


0118 


47 


284 




LD 


B, A 


0119 


214020 


285 




LD 


HL,SIOFLG 


one 


CBB6 


286 




RES 


6, (HL) 


011E 


CB78 


287 




BIT 


7, B 


0120 


C43801 


288 




CALL 


NZ, SETEFF 


0123 


CB70 


289 




BIT 


6, B 


0125 


C43501 


290 




CALL 


NZ,SETCRC 


0128 


CB68 


291 




BIT 


5, B 


012A 


C43201 


292 
293 


CHBSR1: 


CALL 


NZ,SETOVR 


012D 


3E30 


294 




LD 


A, SRCRES 



ASM 5 9 



(SET MC FLAG 



CLEAR MC FLAG 
SET TX INACTIVE 
START RESPONSE TIMER 



(RESET TBE INT. PEND 



i CH. B EXTERNAL/STATUS CHG 
? GET FLAG BYTE 



READ RRO 
STORE IN 7.B 
CHECK DCD BIT 

j CHECK CTS BIT 

i CHECK ABORT BIT 

i CHECK MC FLAG 
; BRANCH IF CLEAR 

i RESET ESC 



;CH. B RX CHAR AVAIL 
;GF1 READ BUFF PTR 



iCH. B SPECIAL RX COND 

;READ RR1 

;SAVE IN %B 

, CLEAR CRC ERROR FLAG 
CHECK EOF BIT 
BRANCH IF NOT EOF 
CHECK CRC ERROR 

; CHECK OVRRUN BIT 
; ERROR RESET CMD 
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LOC 


OBJ CG 


012F 


D303 


0131 


C9 


0132 


CBEE 


0134 


C9 


0135 


CBF6 


0137 


C9 


0138 


CBFE 


013A 


C9 


013B 


CD5901 


013E 


3E28 


0140 


D301 


0142 


C9 


0143 


CD5901 


0146 


3E10 


0148 


D301 


014A 


C9 


014B 


CD5901 


014E 


DBOO 


0130 


C9 


oisi 


CD5901 


0154 


3E30 


0156 


D301 


0158 


C9 



TEST. SDLC 

OBJ CODE M STMT SOURCE STATEMENT ASM 5 9 

295 OUT (SIOCB)*A 

296 RET 

297 SETOVR: 

298 SET 5, (HL) 

299 RET 

300 SETCRC: 

301 SET 6, (HL) 

302 RET 

303 SETEFF: 

304 SET 7, (HL) 

305 RET 
306 

307 CHATBE: 

308 CALL SAVE i CH. A TX BUFFER EMPTV 

309 LD A, TBERES 

310 OUT (SIOCA),A 

311 RET 
312 

313 CH(fl£SC: 

314 CALL SAVE i CH. A EXTERNAL/STATUS CHG 

315 LD A, ESCRES 

316 OUT (SIOCA),A 

317 RET 
318 

319 CHV«CA: 

320 CALL SAVE ; CH A RX CHAR AVAIL 

321 IN A. (8I0DA) 
32£ RET 
323 

324 CHA8RC 

325 CALL SAVE , LH. bf'LClAL H* <.«*!!,' 

326 LD A, SRCRKb 

327 OUT <8I0CA)iA 

328 RET 
329 

330 , SAVE REGISTER ROUTINE 
331 

332 SAVE. 

333 EX <SP),HL >W ** HL 

334 PUSH DE , DF 

335 PUSH BC » BC 

336 PUSH AF J 4F 

337 PUSH IX , IX 

338 PUSH IY , 1Y 

339 CALL GO ; PC 

340 POP IY 

341 POP IX 

342 POP AF 

343 POP BC 

344 POP DE 

345 POP HL 

346 EI 

347 RETI 
348 
349 GO 

016F E9 350 JP <HL) 

351 *E 
352 

353 , , CONSTANTS 
354 

355 SIQTA: 

356 DEFB SIOWRO , CHAN RESET 

357 DEFB CHRES 

358 DEFB SI0WR1 , CHAN CHARACS 

359 DEFB WREN+RDY+RXIAP+TXI 

360 DEFB SI0WR4 t MODE 

361 DEFB X16+ST0P2+EVEN+PARITY 

362 DEFB SI0WR5 ; TX PARAMS. 

363 DEFB DTR+TX7+TXEN+RTS 

364 DEFB SI0WR3 i RX PARAMS. 

365 DEFB RX7+RXEN 
f 366 SIOEA: EQU * 

367 
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0159, 


E3 


01 5A 


D5 


01 5B 


C5 


01 5C 


F5 


015D 


DDES 


01 5F 


FDE5 


0161 


CD6F01 


0164 


FDE1 


0166 


DDE1 


0168 


Fl 


0169 


CI 


0J6A 


Dl 


016B 


El 


016C 


FB 


016D 


ED4D 



0170 


00 


a;7i 


18 


0/172 


01 


0173 


D2 


0174 


04 


0175 


4F 


0176 


05 


0177 


AA 


0178 


03 


0179 


41 











TEST. SDLC 






LOG 


OBJ CODE M STMT 


SOURCE 


STATEMENT 




ASM b 9 






368 


SIOTB: 








017A 


00 


369 




DEFB 


SIOWRO 


CHAN RESET 


01 7B 


18 


370 




DEFB 


CHRES 




017C 


02 


371 




DEFB 


SI0WR2 


VECTOR REG 


0J7D 


10 


372 




DEFB 


SIOVEC. AND. 255 




017E 


04 


373 




DEFB 


SI0WR4 


MODE 


017F 


20 


374 




DEFB 


Xl+SDLC+SYNCEN 




0180 


01 


375 




DEFB 


SI0WR1 


CHAN CHARACS. 


0181 


IF 


376 




DEFB 


RXIA+SIOSAV+TXI+EXTI 


0182 


06 


377 




DEFB 


SI0WR6 


ADDRESS 


0183 


9E 


378 




DEFB 


ADDRESS 




0184 


07 


379 




DEFB 


SI0WR7 


FLAG 


0185 


7E 


380 




DEFB 


01111110B 




0186 


05 


381 




DEFB 


SI0WR5 


TX PARAMS. 


0187 


EB 


382 




DEFB 


DTR+TX8+TXEN+RTS+TXCRC 


0188 


03 


383 




DEFB 


SI0WR3 


RX PARAMS. 


0189 


CI 


384 




DEFB 


RX8+RXEN 








385 


SIOEB: 


EQU 


* 








386 














387 


CLST: 








018A 


28 


388 




DEFB 


28H 


PORT B MODE 


018B 


00 


389 




DEFB 


OOOOOOOOB 




018C 


2B 


390 




DEFB 


2BH 


DATA DIRECTION 


018D 


EE 


391 




DEFB 


11101110B 




018E 


1C 


392 




DEFB 


1CH 


CT1 MODE 


018F 


C2 


393 




DEFB 


11 00001 OB 




0190 


16 


394 




DEFB 


16H 


CT1 TC MSB 


0191 


00 


395 




DEFB 







0192 


17 


396 




DEFB 


17H 


LSB 


0193 


60 


397 




DEFB 


CIOCNT 




0194 


01 


398 




DEFB 


1 


MASTER CONFIG. REG 


0195 


FO 


399 




DEFB 


11110000B 




0196 


OA 


400 




DEFB 


10 


CT1 TRIGGER 


0197 


06 


401 




DEFB 


00000 11 OB 








402 


CEN3: 


EQU 


* 








403 


*E 












404 














405 


, ; 


DATA AREA 








406 










2000 




407 




ORG 


RAM 




2000 




408 




DEFS 


64 


STACK AREA 






409 


ST<*K: 


EQU 


* 




2040 




410 


SIOFLG 


DEFS 


1 


SIO FLAG BYTE 


2041 




411 


BYTES- 


DEFS 


1 


BUFFER BYTE COUNT 


2042 




412 


RSPTMR 


DEFS 


1 


RESPONSE TIMER 


2043 




413 


BUFPTR 


DEFS 


2 


BUFFER POINTER 


2045 




414 


BUFFER 


DEFS 


64 


BUFFER 


2085 




415 


RBPTR: 


DEFS 


2 


READ BUFF PTR 






416 


RBUF: 


EQU 


* 








417 














418 




END 







617-1564-0007 



2-82 



2-25-81 



Binary Synchronous 
Communication 
Using the Z80 SIO 



Zilog 



Application Note 



October 1980 



A popular communication protocol used to 
exchange Information between data processing 
devices has been In use for some time. This 
protocol, developed by IBM, Is called binary 
synchronous protocol, or blsync. The Z80 SIO 
provides a flexible and powerful tool for the 
Implementation of the blsync protocol. How- 
ever, there are some design considerations 
that require special attention. This paper 
will discuss these design considerations and 
offer an approach to using blsync with the 
Z80 SIO. Specific examples are presented and 
readers who are unfamiliar with the blsync 
protocol should refer to the ANSI standard 
(I) or the IBM publication (2) listed at the 
end of this paper. 

Blsync Is a character-oriented protocol with 
Information transmitted In blocks between two 
(or more) data communication devices. The 
medium through which this Information Is 
conveyed is called the data link. The par- 
ticular data link discussed In this paper Is 
a point-to-point link using the ASCII trans- 
mission code. Other codes, such as EBCDIC, 
are not covered, but the format for blsync Is 
basically the same. The data link consists 
of a master station (usually a computer) and 
a slave station (usually a terminal) with the 
associated communication gear in between — 
modems, phone lines, etc. The master station 
controls message flow by polling and select- 
ing the slave station. Polling Involves send- 
ing a general request message to the slave 
station (s) to determine whether or not any of 
the slaves have data to send (traffic). If a 
slave station does have traffic, It responds 
to the pol I and the master can then select 
that particular slave for Information ex- 
change. Slaves can only respond to a master 
device and cannot Initiate communication on 
the data link. 

Information Is exchanged by means of a well- 
defined block structure. Message blocks 
consist of a header, body, and trailer 



(Figure 1). The header Is made of two or 
more SYN characters (hence the name blsync), 
a start of header (SOH) character, and ad- 
dressing and control Information for a par- 
ticular slave station. 
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Header 



Body 



Figure 1» Basic Message Block Format 
for Blsync Protocol 



The body begins with a start of text (STX) 
character and encompasses the entire text 
Information. The body generally contains 
ASCII text data, although 8-bit binary data 
can be transmitted using transparent text 
mode. 

The trailer contains the end of text (ETX) 
character and the block check character 
(BCC). The BCC is used for detecting errors 
through "cyclic redundancy checking" (CRC) or 
"longltudal redundancy checking" (LRC). 

Error detection Is essential when transfer- 
ring Information between data processing 
equipment. Since ASCII specifies only seven 
bits for Its code, the eighth bit Is used for 
vertical redundancy checking (VRC), more 
commonly known as character parity. In syn- 
chronous communications, character parity Is 
generally odd, whereas In asynchronous com- 
munications It Is even. Figure 2 shows typi- 
cal ASCII characters with parity. The SIO 
can be programmed for 7-blt characters with 
odd parity enabled to minimize software over- 
head. 
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Figure 2 m Odd VRC. 
Number of 1s should be odd* 



Because VRC applies only to the Individual 
character, the entire message block has an 
LRC that makes up the BCC. The LRC is a 
simple bit position checksum where the number 
of Is for each position (0 through 6) is even 
for a block of data. Since the BCC Is a 
character, LRC Is subject to the same char- 
acter parity rules as the rest of the data 
block. The LRC includes all characters, 
except SYN, starting with the first character 
after SOH or STX and up to and including ETX 
In the trailer (Figure 3). Since the SIO 
cannot calculate the LRC, the task is left up 
to the user. LRC can be generated on a 
microprocessor with little effort by taking 
the message block and XORing the data with an 
Initial value of zero to provide even LRC. 
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Included In BBC 
Figure 3« Characters Included In BBC 



Another type of BBC Is generated by a cyclic 
redundancy check (CRC), which results In a 
more powerful method of block checking. 
CRC- 12 Is used for 6-bit transmission code 
and CRC-16 Is used for 8-bit transmission 
code. CRC is used in lieu of character 
parity and LRC, as with transparent text mode 
operation. 

The remainder of this paper Illustrates how 
to use the SIO in three special cases of the 
bisync protocol: transparent text mode, 
abort/ interrupt procedures, and error re- 
covery procedures. 

Transparent text mode is useful in bisync 
when information exchanged between master and 
slave Is not ASCII data. For example, a 
binary data file (object program) might be 
sent from master to slave. ASCII transmis- 
sion code is only seven bits long making it 
difficult to send 8-bit binary data. One 
alternative is to convert the binary data to 
ASCI I hex format at the master, transmit it 
to the slave and reconvert it back into 
binary at the slave. However, two disadvan- 



tages result from this. First, the master 
and slave require a means of conversion, by 
either software or hardware, adding cost to 
the data link. Since the slave (terminal) is 
burdened most by this, such an approach Is 
usual ly not feasible. The other disadvantage 
is that the exchange of information is slower 
since two (or more) ASCII characters are sent 
for every eight bits of binary data. The 
bisync protocol has provisions for sending 
8-bit binary data by using transparent text 
mode transmission. In this mode, character 
parity is disabled, allowing the full eight 
bits to be used for data. However, to allow 
control within the constraints of the proto- 
col, there are certain limitations on the 
binary data pattern. The primary difference 
is that during transparent mode some communi- 
cation control characters are preceded by a 
DLE character, actually making the control 
characters a two-character sequence. To 
distinguish a data byte from a control DLE, 
the protocol specifies Insertion of another 
DLE. The receiver then throws away the first 
DLE, keeping the second as data. Table 1 
shows the communication control characters 
that are valid during transparent mode. 

Another character change occurs when the SYN 
character is used for line fill. Normally, 
the SYN character Is ignored, but during 
transparent mode the SYN is preceded by a 
DLE, and both are consequently ignored by the 
receiver. In the event that the CPU does not 
have a character ready to send, the SIO auto- 
matical ly inserts SYN characters into the 
data stream. With the SIO programmed for 
16-bit sync characters, two syncs are sent 
from the SIO (write registers WR6 and WR7> 
when its transmit buffer Is empty. In trans- 
parent mode, the user must change WR6 and WR7 
to DLE, SYN in order for the SIO to provide 
the proper line fill characters. In accord- 
ance with the ANSI standard, line fill char- 
acters are not included in the SIO CRC calcu- 
lation during transmit. During reception In 
transparent mode, the software must disable 
CRC accumulation when the DLE SYN character 
sequence is detected. 

While in transparent mode, the user must be 
concerned with the error detection codes. If 
parity is enabled in the SIO normally, it 
must be disabled during transparent mode. 
This change In SIO operation affects both 
transmit and receive and should therefore be 
considered if using full duplex. 

Table 1. Control Codes Used 
In Transparent Mode 



DLE 


STX 


Start of transparent text 


DLE 


ETB 


End of transparent text block 


DLE 


ETX 


End of transparent text 


DLE 


SYN 


Idle sync 


DLE 


ENQ 


Enquiry 


DLE 


DLE 


DLE data 


DLE 


SOH 


Start of transparent header 
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Since the SIO allows CRC enable/disable on 
the fly, the software can easily control CRC 
accumulation In both receive and transmit. 
During transmit, the CRC must be enabled/ 
disabled before the character Is transferred 
Into the serial shift register. During re- 
ceive, the CRC accumulation Is delayed eight 
bits. After the character Is transferred 
from the serial shift register Into the 
buffer, the user has to read that character, 
decide whether or not to continue CRC accumu- 
lation, and disable/enable CRC before the 
next character Is transferred to the buffer. 
This Is not generally a problem, since char- 
acter transfers occur about every 833 micro- 
seconds at 9600 baud. Table 2 shows the char- 
acters Included and omitted In the CRC during 
transparent mode. 



sequence Is used. Since a block abort puts 
the data link back In nontrans parent mode, 
NAK Is the valid response the receiver should 
send In both transparent and nontransparent 
modes. 

The sending station abort Is similar to the 
block abort, except that the sending station 
does not necessarily do a block abort but 
simply ends the current message block, waits 
for a response or timeout, and then sends an 
EOT to regain control of the data link. The 
sending station abort Is useful when trans- 
mission to a particular receiver Is necessary 
due to a higher priority message, buffer 
overflow condition, error detection, etc. 
Once the sending station abort sequence Is 
made, the master can perform any data link 
control function. 



Table 2« Characters Included/Omitted In 
CRC During Transparent Mode 



Omitted from CRC 



Included In CRC 



DLE 


SYN 


DLE of DLE DLE 


DLE 


SOH 


ETX of DLE ETX 


DLE 


STX* 


ETB of DLE ETB 
STX of DLE STX** 



*lf not preceded by 
transparent header 
within same block 



**lf preceded by DLE 
SOH within same 
block 



When CRC accumulation Is to be resumed, the 
software should enable CRC before the desired 
character Is transferred to the receive 
buffer. For example, suppose a DLE pair Is 
received during transparent text mode. The 
SIO generates an Interrupt when the first DLE 
Is transferred to the receive buffer. The 
driver program reads the DLE and Immediately 
disables CRC. When the next Interrupt 
occurs, the driver reads the second DLE and 
Immediately enables CRC to Include the second 
DLE Into the CRC accumulation. 

The second category of Interest includes 
abort and Interrupt procedures. There are two 
types of aborts: block abort and sending 
station abort. There are three types of 
interrupts: termination interrupt, reverse 
Interrupt and temporary interrupt. 

The block abort Is used by the sending sta- 
tion when, in the process of transmitting a 
data block, the sending station detects an 
error condition In the data and decides to 
terminate the block so that the receiving 
station will discard it. In nontransparent 
mode, block abort Is accomplished by ending 
the block with an ENQ character, instead of 
ETX or ETB. The sending station then waits 
for a reply from the receiver, which should 
be a NAK. The transparent mode procedure Is 
Identical except that a DLE ENQ character 



From the receiver side, a termination Inter- 
rupt causes the sending station to stop 
transmission. Such a procedure Is useful when 
the receiver cannot accept any more data or 
Incurs an error condition, such as paper jam, 
card jam, hardware error, etc. To accomplish 
a termination Interrupt, the receiving sta- 
tion sends an EOT Instead of the normal re- 
sponse. The EOT resets a I I stations on the 
link and allows the master to Issue any con- 
trol sequence. 

The reverse Interrupt (RINT) Is used when the 
receiving station needs to transmit during 
reception of several message blocks. The 
RINT occurs when a receiver detects a valid 
CRC or LRC and, Instead of returning an ACK, 
sends a DLE "<" character sequence to signal 
an affirmative acknowledgement and to stop 
transmission of data. Some exceptions and a 
more detailed description of RINT can be 
found In the ANSI standard. 

The temporary interrupt procedure, WACK (Wait 
Before Sending Positive Acknowledge), is used 
by the receiving station to indicate positive 
acknowledgement and an inability to receive 
more data. Such a response may be necessary 
when the receiving station cannot accept data 
continuously, such as during a printing 
operation. The WACK consists of a DLE ■•;« 
character sequence and Is sent In place of an 
ACK or ACKn. The sending station then sends 
ENQs (Enquiry) until the receiving station 
stops sending WACKs. The sending station can 
resume transmitting data when the receiving 
station sends an ACK or ACKn. 

Recovery procedures provide a means of pre- 
venting data link instability. The recovery 
mechanism consists mainly of timers, grouped 
Into four basic areas, and a NAK counter. 
The NAK counter Is used to prevent repeated 
NAKs from Inhibiting further communications. 
The sending unit counts how many NAKs it 
receives for a particular data block so that 
after a predetermined number of retries, it 
can recover and pursue another course of 
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action. The particular count value and 
course of action taken when the count expires 
are left up to the user. 

Four timers (timer A or response timer, timer 
B or receiver timer, timer C or gross timer, 
and timer D or no activity timer) prevent the 
data link from getting "hung" or going idle 
for extended periods of time. General ly, the 
shortest interval is used with timer A, and 
the longest interval Is used with timer D. 
For maximum system efficiency, however, the 
receiver timer (timer B) should timeout 
before the response timer (timer A). The 
particular implementation of these timers 
varies from system to system, and some flexi- 
bility of exact timer values is left up to 
the user. 



properly decode CRC. Because of the char- 
acter delay in the SIO during CRC accumula- 
tion, about 20 clock cycles are necessary 
after the last CRC byte is sent to ensure 
adequate decoding time. (See the SIO Techni- 
cal Manual for further details.) The SIO 
could be programmed to send pad characters 
either by disabling parity and sending 8-bit 
FFs (hex) or by filling WR6 and WR7 with FF 
hex. If enabled, the SIO automatically sends 
whatever is in its sync registers upon trans- 
mit underrun. Multiple message blocks do not 
have to be separated by pad characters as 
long as CRC Is valid for the previous message 
block. However, to insure adequate time for 
the receiver to process CRC, it is recom- 
mended that at least two pad characters 
fol low the last character of a block. 



Since it is assumed that interrupts will be 
used with the SIO, an Interrupt driven re- 
ceiver timer count is kept in memory and is 
reinitialized each time a character is re- 
ceived (receive Interrupt). The same applies 
for the response timer, except that when a 
timeout occurs, the transmit driver has 
several options to follow. 

If the SIO Is set to transmit CRC on transmit 
underrun, then the driver could simply set 
its flags and not fill the buffer. This 
allows a normal exit, since the SIO will then 
send Its CRC bytes. If the SIO is set to not 
transmit CRC on transmit underrun, then it 
sends sync characters (SYN SYN or OLE SYN, 
whichever was last written to WR6 and WR7) 
until the transmit buffer is filled or trans- 
mit data is set to marking. 

In any event, enough time must be allowed 
after CRC Is sent so that the receiver can 



Using the SIO for the bisync protocol Is 
fairly straightforward. Care should be exer- 
cised when using the SIO In transparent text 
mode, but the implementation is greatly 
simplified by the SIO's flexibility, as com- 
pared to other serial communications ICs. 
The CRC capabilities of the SIO provide a 
powerful means of maintaining maximum data 
integrity with minimum software overhead. 
Coupled with the DMA and the interrupt capa- 
bilities of the Z80 processor, the user will 
find the SIO an excellent choice in serving 
data communication needs. 



(1) American National Standards Institute. 
ANSI X3.28 - 1976. 

(2) "General Information - Binary Synchronous 
Communications." Pub. number GA27- 
3004-2. 
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INTRODUCTION Serial data communication is among the most 
widely used forms of exchanging Information 
with and between computers. The rapid ex- 
pansion of this form of communication has 
created the need for low-cost, efficient, and 
flexible peripheral devices that provide the 
user with a wide variety of options. The Z80 
DART is designed to fill this need by pro- 
viding two independently programmable, 



asynchronous communication channels for a 
Z80-based system. 

This application brief describes the use of 
the Z80 DART in a Z80-based system. Further 
Information on the Z80 CPU and Z80 DART Is 
available in the Zi log Data Book (document 
number 00-2034-A), Z8400 Z80 CPU Product 
Spec! f Ication (document number 00-2001-A), 
and the Z8470 Z80 DART Product Specification 
(document number 00-2044-A). 



HARDWARE The hardware for this application consists of 

a Z8400 Z80 CPU, Z8470 Z80A DART, Z8536 CIO, 
4K ROM, and 4K RAM. Figure 1 shows a block 
diagram of the system. The CIO supplies the 
bit rate clock for the DART and allows the 
baud rate for each channel to be determined 
by the software. 



The DART-to-CPU interface consists of eight 
bidirectional data lines, seven control 
lines, and three daisy chain Interrupt con- 
trol lines. The data lines are used to 
transfer data between the DART and the CPU. 
The direction of data flow on the data lines 
Is determined through the use of the CE, RD, 
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and IORQ control lines. When CE and IORQ are 
active, a data transfer occurs between the 
CPU and DART. I f RD is active at the same 
time^data is sent from the DART to the CPU. 
I f RD is not active, data is sent from the 
CPU to the DART. M1 signals an interrupt 
ackno wled ge cycl e fro m the CPU in conjunction 
with IORQ. The RESET line performs a device 
reset on the DART, a I lowing it fo be placed 
In a known state. The remaining two control 
lines determine which of the four ports are 
being accessed. Table 1 shows the rela- 
tionship of these two lines to the ports. 

Table 1. DART Port Addressing 



Port- 


c/5 


B/A 


Channel A Data 








Channel B Data 





1 


Channel A Control 


1 





Channel B Control 


1 


1 



C/D and B/A are usual ly tied to the lowest 
two CPU address lines used for I/O device 
selection. Figure 2 shows the device-select 
decode logic used in this application. 
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NOTE Only the lower eight bits of the 

address bus are used for I/O select 

Figure 2. DART Device Select Logic 

External connections to the Z80 DART include 
serial data and control lines and modem con- 
trol lines. The serial data lines are 
Transmit Data (TxD) and Receive Data (RxD) 
for each channel. Separate transmit and 



rece ive c lock in puts are available on channel 
A (TxCA and RxCA), white a combined 
transmit/r eceive clock input is provided for 
channel B (TxRxCB). To all ow se par ate baud 
rates for both channels, TxCA and RxCA are 
tied together and co nnected to one counter/ 
timer output, and TxRxCB is connected to 
another counter/timer output. This provides 
the user with a simple, software-programmable 
baud rate generator. 

The modem control lines provide the user with 
a means of controlling some external device 
such as a modem. This is particularly useful 
for remote applications in which the CPU must 
determine a course of action based on the 
status of the modem controj_ I ines. For ex- 
ample, Ring Indicator (Rl) can be used to 
signal the CPU that an incoming call needs to 
be answered, or Data Terminal Ready (DTR) can 
be used in conjunction with Data Carrier 
Detect (DCD) to signal the modem that data 
communications can take place. DTR remains 
active as long as the DART is communicating 
over the serial data link. The CPU can "hang 
up" or disconnect the telephone connection by 
deactivating DTR. Finally, Request To Send 
CRTS) and Clear To Send (CTS) are useful in a 
multidrop configuration; that is, when three 
or more modems are connected to the same 
telephone line RTS is used to switch the 
carrier for a particular modem on or off 
under software control. CTS is monitored so 
that after RTS is activated the CPU knows 
when to start sending data. 

The IEI, IE0, and fNT lines form the Z80 
daisy-chain interrupt controls th at enable 
proper interrupt sequencing. INT is an 
open-drain, active Low output that is con- 
nected to the Z80 CPU INT input, along with a 
pu I I up resistor. IEI is usually connected to 
the preceding device in the daisy chain or is 
tied High if there is no preceding device. 
I EO is connected to the following device in 
the daisy chain or is left open. This 
application example uses interrupts with the 
Status Affects Vector (SAV) programming op- 
tion. Interrupts are prioritized internally 
in the DART according to the various condi- 
tions. There are four separate interrupt 
groups for each channel. Table 2 shows the 
relative priorities of these interrupts. 

Table 2. DART Interrupt Priority 



Priority 


Function 


Highest 
Lowest 


Ch. A Special Rx Condition 

Ch. A Rx Char. Available 

Ch. A Tx Buffer Empty 

Ch. A External /Status Change 

Ch. B Special Rx Condition 

Ch. B Rx Char. Available 

Ch. B Tx Buffer Empty 

Ch. B External /Status Change 
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PROGRAMMING Programming the Z80 DART consists of two 
parts: initialization and program operation. 
Initialization Includes def ining the oper- 
ating characteristics of the DART. This is 
done by writing a series of bytes to the 
control port of each channel, A detailed 
description of the programming for the DART 
can be found in the DART Product Specifica- 
tion (document number 00-2044-A), A listing 
containing an initialization routine for the 
DART can be found in the appendix of this 
brief. 

Once initialized, the DART interrupts the CPU 
for certain conditions that occur. These 
conditions include Transmit Buffer Empty, 
Receive Character Avai I able, Special Receive 
Condition, and Externa I /Status Change for 
each channel. 

The DART generates a Transmit Buffer Empty 
(TBE) interrupt when a character Is trans- 
ferred from the internal buffer to the shift 
register. The interrupt service routine 
determines whether to send another character 
to the DART or to issue a Reset Tx Interrupt 
Pending command. If a character is loaded 
into the DART, the Interrupt condition is 
automatically removed. If a character is not 
loaded, the software issues a Reset Tx Inter- 
rupt Pending command to remove the interrupt 
condition and also sets an Internal program 
status flag that signals the transmit channel 
as inactive. When transmission starts from 
an inactive condition (such as after initial- 
ization), the main program must activate the 
transmitter by sending a character to the 
DART. In this application, a call to the 
transmit Interrupt service routine activates 
the transmitter after the buffer and pointers 
have been initialized. 

The Receive Character Available (RCA) Inter- 
rupt occurs after the DART transfers a char- 
acter from the serial shift register to the 
receiver FIFO. The DART can store up to 
three characters In the FIFO, giving the CPU 



some flexibility in receive Interrupt timing. 
Read Register (RRO, bit 0) can be checked 
to see if any more characters are In the FIFO 
before exiting the interrupt service routine. 
If the DART Is programmed so that parity does 
not affect the interrupt vector, parity 
errors must be checked in the receive service 
routine. This is done by writing a register 
pointer to the DART for Read Register 1 (RR1) 
and then reading the contents. The bit test 
Instructions of the Z80 CPU are particularly 
useful In determining which bits are set or 
cleared. Processing for these errors Is the 
same as processing for the Special Receive 
Condition. 

The DART generates a Special Receive Condi- 
tion (SRC) interrupt if it detects a parity 
error, overrun, or framing error during re- 
ception. When this occurs the programmer 
should reset the error condition by issuing 
an Error Reset command to the DART. After 
the Error Reset command is issued, the pro- 
grammer should read and discard the data if 
necessary. If the data Is not discarded, 
then an RCA Interrupt occurs Immediately 
after exiting the SRC service routine. 

An Externa I /Status Change (ESC) Interrupt 
occurs when the DART detects a change In the 
external signals (Rl, CTS, DCD) or when a 
receive break condition Is initiated or ter- 
minated. This Is useful In monitoring the 
Interface to the modem where a software flag 
Is set when the break condition is detected 
and reset when the break condition is clear- 
ed. With CTS, DCD, and Rl, the same proce- 
dure Is followed as with a break condition. 
However, If the auto enable bit Is set In the 
DART, the DART does not transmit data until 
CTS becomes active, nor does It receive data 
until DCD becomes active. 

The appendix contains the listing of a test 
program for the DART, While It is by no 
means complete, it does highlight the Inter- 
rupt features of the Z80 DART, 



CONCLUSION As do other Z80 peripheral products, the Z80 
DART interfaces well with the Z80 CPU, The 
software required to utilize the features of 
the DART Is conducive to efficient program- 
ming. Interrupts provide a key method of 
maintaining efficient system operation, keep- 
ing CPU processing overhead to a minimum. 

Other methods of utilizing the DART include a 
"polled" (non I nterrupt) system. Because the 



Z80 CPU has three interrupt modes, the DART 
can be used with the CPU without vectored 
interrupts. However, such simplicity is 
usually at the expense of program size and 
speed. 

Nevertheless, the user will find the Z80 DART 
a viable alternative to more expensive de- 
vices when considering the asynchronous com- 
munication requirements for any Z80 system. 



APPENDIX Fol lowing Is the listing of a DART test pro- 
gram. Note that all interrupt service rou- 
tines are dummy routines, except DATBE, which 



transfers characters from the buffer to Port 
A transmitter. 
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START 




INITIALIZE CPU 



INITIALIZE DART 



f enter) 



SAVE REGISTERS 



INPUT DATA FROM DART 



CLEAR FLAG BYTE 



INITIALIZE CIO 




yi 




FILL BUFFER WITH 
DATA PATTERN 




U 




ACTIVATE Tx 






^ 


i 


' 


JP LOOP 









a) Main Program 



Q ENTER ) 



SAVE REGISTERS 



GET BUFFER CHARACTER 



OUTPUT TO DART 



b) DATBE-DART Channel A 
Transmit Buffer Empty 
Interrupt Service Routine 



NOTE. DARCA, DAESC, AND 

DASRC are dummy routines. 



± 



C EXIT ) 

ICA-Channel / 
racter Interrup 

( ENTER ) 



c) DARCA-Channel A Receive 
Character Interrupt Routine 



SAVE REGISTERS 



J_ 



OUTPUT ESC RESET 
COMMAND 



UPDATE FLAGS 



d) DAESC-Channel A 

External/Status Change 
Interrupt Routine 



( ENTER ) 



SAVE REGISTERS 



OUTPUT SRC RESET 
COMMAND 



INPUT DATA 



UPDATE FLAGS 



( EXIT ) 



e) DASRC-Special Receive 
Condition Interrupt Routine 

Figure 3. Flow Diagram for DART Test Program 



751-1809-0001 



2-90 



2/18/81 



LOC 



TEST DART 
OBJ CODE M STMT SOURCE STATEMENT 



ASM 



DART TEST PROGRAM 



3 
4 
5 


RAM 


EQUATES 
EQU 


2000H 




, RAM ORIGIN 


6 


RAMSIZ: 


EQU 


1000H 




, RAM SIZE 


7 


CIOA 


EQU 


8 




, < JCi PORT A 


S 


CIQB 


EQU 


CIOA+1 




, CIO PORT B 


9 


CIOC 


EQU 


CIOA+2 




, CJG PORT C 


10 


CIOCTL. 


EQU 


CIQA+3 




, C30 CTRL PORT 


11 


BAUD 


EQU 


9600 




, ASYNC BAUD RATE 


12 


RATE- 


EQU 


BAUD/100 




13 


CIOCNT 


EQU 


576/RATE 




14 


DRTDA: 


EQU 


4 




> DART PORT A DATA 


15 


DRTCA 


EQU 


DRTDA+1 




, DART PORT A CTRL 


16 


DRTDB 


EQU 


DRTDA+2 




, DART PORT B DATA 


17 


DRTCB 


EQU 


DRTDA+3 




, DART PORT B CTRL 


18 












19 


, 


DART PARAMETERS 






20 












21 


DRTWRO- 


EQU 









22 




CHRES 


EQU 


18H 


, CH. RESET CMD 


23 




ESCRES 


EQU 


10H 


i ESC RESET CMD 


24 




TBERES- 


EQU 


28H 


> TBF RESET CMD 


25 




SRCRES 


EQU 


30H 


, SRC RESET CMD 


26 




RETIA- 


EQU 


38H 


, RET I CH A 


27 




ENINRX 


EQU 


20H 


, ENAB INT. NEXT RX 


28 












29 


DRTWR1. 


EQU 


1 






30 




WREN 


EQU 


80H 


, WAIT/RDY ENABLE 


31 




RDY. 


EQU 


40H 


, READY FUNCT. 


32 




WRONR: 


EQU 


20H 


i WAIT/RDY ON RX 


33 




RXIFC: 


EQU 


8 


, RX INT FIRST CHAR 


34 




RXIAP: 


EQU 


10H 


; RX INT ALL + PARITY 


35 




RXIA- 


EQU 


18H 


; RX INT. ALL 


36 




DRTSAV- 


EQU 


4 


; STATUS AFFECTS VECT 


37 










; (CH B ONLY) 


38 




TXI. 


EQU 


2 


,TX INT. ENABLE 


39 




EXTI 


EQU 


1 


;EX1. INT. ENABLE 


40 












41 
42 
43 


DRTWR2. 


EQU 


2 




; (CH. B ONLY) 


DRTWR3: 


EQU 


3 






44 




RX8: 


EQU 


OCOH 


, RX 8 BITS 


45 




RX6 


EQU 


80H 


, RX 6 BITS 


46 




RX7 


EQU 


40H 


, RX 7 BITS 


47 




RX5- 


EQU 





,RX 5 BITS 


48 




AUTOEN- 


EQU 


20H 


* AUTO ENABLES 


49 




RXEN 


EQU 


1 


; RX ENABLE 


50 












51 


DRTWR4: 


EQU 


4 






52 




X64 


EQU 


OCOH 


, 64X CLOCK 


53 




X32: 


EQU 


80H 


, 32X CLOCK 


54 




X16: 


EQU 


40H 


i 16X CLOCK 


55 




XI. 


EQU 





, IX CLOCK 


56 




STOP 2: 


EQU 


OCH 


,2 STOP BITS 


57 




STOP 15 


EQU 


8 


,1.5 STOP BITS 


58 




ST0P1 


EQU 


4 


; 1 STOP BIT 


59 




EVEN 


EQU 


71 


, rvc-N PAR IT y 


60 




PAP I TV 


EQU 


1 


i PAKHY ENABLE 


61 












62 


DR TWR 5 


EQU 


5 






63 




D1R 


EQU 


80H 


, AC "I IVATE DTP 


64 




TX8 


EQU 


60H * 


> rx 6 BITS 


65 




TX6 


EQU 


40H 


, 1 X 6 E I TS 


*6 




TX7 


EQU 


20H 


. T'X 7 BITS 


67 




TX"? 


EQU 





. TX 5 BITS 


68 




UPEAK 


EQU 


10H 


, 7 X BREAK 


&* 




"i XF.N 


EQU 


h 


, IX ENABLE 


70 




R7S 


EQU 


2 


, ACTIVATE RTS 


71 


*E 










72 
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LOC 



TEST. DART 
OBJ CODE M STMT SOURCE STATEMENT 



ASM 5. 9 



0000 
0000 



0010 



C32000 



0010 


7E0O 


0012 


9000 


0014 


8A00 


0016 


A400 


0018 


B800 


001A 


D100 


001C 


CBOO 


001E 


E500 


0020 


318320 


0023 


ED5E 


0025 


3E00 


0027 


ED47 


0029 


CD4800 


002C 


210020 


002 F 


063E 


0031 


78 


0032 


F640 


0034 


77 


0035 


23 


0036 


10F9 


0038 


360D 


003A 


23 


003B 


360A 


003D 


210020 


0040 


224120 


0043 


CDB800 



0046 



18FE 



0048 


211001 


004 B 


0E05 


004 D 


060A 


004F 


EDB3 


0051 


211A01 


0054 


0E07 


0056 


060C 


0058 


EDB3 


005A 


AF 


005B 


324020 


00 5E 


DBOB 


0060 


AF 


0061 


D30B 


0063 


DBOB 


0065 


AF 


0066 


D30B 


0068 


3C 


0069 


D30B 


006E 


AF 


006C 


D30B 


006E 


3EFE 


0070 


D30B 


0072 


D30B 


0074 


212601 


0077 


0620 


0079 


OEOB 


751-1809-0001 





73 


, , 


•*** MAIN PROGRAM #** 




74 










75 




ORG 







76 




JP 


BEGIN 


;G0 MAIN PROGRAM 


77 










78 


, 


INTERRUPT VECTORS 




79 










80 




ORG 


*. AND. OFFFOH. OR. 


10H 


81 


INTVEC: 








82 


DRTVEC. 








83 




DEFW 


DBTBE 




84 




DEFW 


DBESC 




85 




DEFW 


DBRCA 




86 




DEFW 


DBSRC 




87 




DEFW 


DATBE 




88 




DEFW 


DAESC 




89 




DEFW 


DARCA 




90 




DEFW 


DASRC 




91 










92 


BEGIN- 








93 




LD 


SPi STAK 


; INIT SP. 


94 




IM 


2 


; VECTOR INTERRUPT MODE 


95 




LD 


A, INTVEC/256 


; UPPER VECTOR BYTE 


96 




LD 


I, A 




97 




CALL 


INIT 


; INIT DEVICES 


98 




LD 


HL, BUFFER 




99 




LD 


B, 62 




100 


LOOP: 








101 




LD 


A, B 




102 




OR 


40H 




103 




LD 


<HL)> A 




104 




INC 


HL 




105 




DJNZ 


LOOP 




106 




LD 


(HL), 13 


;CR 


107 




INC 


HL 




108 




LD 


(HL), 10 


;LF 


109 




LD 


HL, BUFFER 




110 




LD 


(BUFPTR),HL 




111 




CALL 


DATBE 


; WAKE TX 


113 




JR 


* 


;LOOP FOREVER 


114 










115 


I NIT 








116 


DRTINI- 








117 




LD 


HL, DRTTA 


; INIT CH. A 


118 




LD 


C, DRTCA 




119 




LD 


B, DRTEA-DRTTA 




120 




OTIR 






121 




LD 


HL, DRTTB 


> INIT CH B 


1 22 




LD 


C, DRTCB 




123 




LD 


B, DRTEB-DRTTB 




124 




OTIR 






125 




XOR 


A 


; CLEAR FLAG BYTE 


126 




LD 


(DRTFLG), A 




127 


CIOINI 








128 




IN 


A, (CIOCTL) 


j INSURE STATE 


129 




XOR 


A 


; POINT TO REG 


130 




OUT 


(CIOCTL), A 




131 




IN 


A, (CIOCTL) 




132 




XOR 


A 




133 




OUT 


(CIOCTL), A 




134 




INC 


A 


; WRITE RESET 


135 




OUT 


(CIOCTL), A 




136 




XOR 


A 


, ELSE, CLEAR RESET CON; 


137 




OUT 


(CIOCTL), A 




138 




LD 


A, OFEH 


, (FUDGE FOR CIO QUIRK) 


139 




OUT 


(CIOCTL), A 




140 




OUT 


(CIOCTL), A 




141 




LD 


HL, CLST 


, INIT CIO 


142 




LD 


B, CEND-CLST 




143 




LD 


C, CIOCTL 
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LOG 



TEST. DART 
OBJ CODE M STMT SOURCE STATEMENT 



ASM 5. 9 





007B 


EDB3 


144 




OTIR 








007D 


C9 


145 
146 
147 


*E 


RET 












148 


, ; 


SUBROUTINES 










149 
















150 




SETUP 


FOR ASYNC AS 










151 






9600 BAUD 










152 






2 STOP BITS 










153 






EVEN PARITY 










154 






7 BIT CHARACTERS 








155 
















156 




DRTFLG - X X 1 1 X 


X 1 1 








157 






/ ! 


i \ 








158 






ERROR ASLEEP 


ERROR ASLEEP 








159 






CHANNEL B 


CHANNEL A 








160 
















161 


DBTBE: 










007E 


CDF900 


162 




CALL 


SAVE 


, CH. B TX BUFFER EMPTY 




0081 


3E00 


163 




LD 


A, DRTWRO 


; POINT TO REG. 




0083 


D307 


164 




OUT 


(DRTCB), A 






0085 


3E28 


165 




LD 


A, TBERES 


, RfrSET TBE 




0087 


D307 


166 




OUT 


(DRTCB), A 






0089 


C9 


167 
168 
169 


DBRCA: 


RET 








008A 


CDF900 


170 




CALL 


SAVE 


;CH. B RX CHAR AVAIL. 




008D 


DB06 


171 




IN 


A, (DRTDB) 


; READ DATA 




008F 


C9 


172 
173 
174 


DBESC- 


RET 








0090 


CDF900 


175 




CALL 


SAVE 


i CH. B EXTERNAL/STATUS 




0093 


3E00 


176 




LD 


A, DRTWRO 


; POINT TO REG. 




0095 


D307 


177 




OUT 


(DRTCB), A 






0097 


3E10 


178 




LD 


A, ESCRES 


, RESET ESC 




0099 


D307 


179 




OUT 


(DRTCB), A 






009B 


3A4020 


180 




LD 


A, (DRTFLG) 


; UPDATE FLAG 




009E 


CBE7 


181 




SET 


4, A 






OOAO 


324020 


182 




LD 


(DRTFLG), A 






00A3 


C9 


183 
184 
185 


DBSRC- 


RET 








00A4 


CDF900 


186 




CALL 


SAVE 


, CH. B SPECIAL RX COND. 




00A7 


3E00 


187 




LD 


A, DRTWRO 






00A9 


D307 


188 




OUT 


(DRTCB), A 






OOAB 


3E30 


189 




LD 


A, SRCRES 


, RESET SRC 




OOAD 


D307 


190 




OUT 


(DRTCB), A 






OOAF 


3A4020 


191 




LD 


A, (DRTFLG) 


i UPDATE FLAG 




00B2 


CBEF 


192 




SET 


5, A 






00B4 


324020 


193 




LD 


(DRTFLG), A 






00B7 


C9 


194 
195 
196 


DATBE- 


RET 








00B8 


CDF900 


197 




CALL 


SAVE 


i CH A TX BUFFER EMPTY 




OOBB 


2A4120 


198 




LD 


HL, (BUFPTR) 


, GET BUFFER PTR 




OOBE 


46 


199 




LD 


B, (HL) 


; GET CHAR 




OOBF 


7D 


200 




LD 


A, L 


; UPDATE PTR. 




OOCO 


3C 


201 




INC 


A 






00C1 


E63F 


202 




AND 


3FH 


; 64 BYTE WRAPAROUND 




00C3 


6F 


203 




LD 


L, A 






00C4 


224120 


204 




LD 


(BUFPTR), HL 






00C7 


78 


205 




LD 


A, B 


i OUTPUT CHAR. 




00C8 


D304 


206 




OUT 


(DRTDA), A 






OOCA 


C9 


207 
208 
209 


DARCA: 


RET 








OOCB 


CDF900 


210 




CALL 


SAVE 


i CH. A RX CHAR AVAIL. 




OOCE 


DB04 


211 




IN 


A, (DRTDA) 






OODO 


C9 


212 
213 
214 


DAESC. 


RET 








00D1 


CDF900 


215 




CALL 


SAVE 


; CH. A EXTERNAL/STATUS 
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LOG 



OBJ CODE M STMT 



TEST. DART 
SOURCE STATEMENT 



ASM 5. 9 



00D4 


3E00 


00D6 


D305 


00D8 


3E10 


OODA 


D305 


OODC 


3A4020 


OODF 


CBC7 


OOE1 


324020 


00E4 


C9 


00E5 


CDF900 


00E8 


3E00 


OOEA 


D305 


OOEC 


3E30 


OOEE 


D305 


OOFO 


3A4020 


00F3 


CBCF 


OOFS 


324020 


OOFS 


C9 



OOF 9 


E3 


OOFA 


D5 


OOFB 


C5 


OOFC 


F5 


OOFD 


DDES 


OOFF 


FDE5 


0101 


CD0F01 


0104 


FDE1 


0106 


DDE1 


0108 


Fl 


0109 


Ci 


010A 


Dl 


010B 


Ei 


010C 


FB 


010D 


ED4D 



01 OF 



01 1A 
01 IB 
011C 
01 ID 
011E 
01 IF 
0120 
0121 
0122 
0123 
0124 
0125 



E9 



01 10 


00 


0111 


18 


0112 


01 


0113 


13 


0114 


04 


0115 


4F 


0116 


05 


0117 


AA 


0118 


03 


01 19 


41 



00 
18 
01 
17 
02 
10 
04 
4F 
05 
AA 
03 
41 



216 
217 
218 
219 
220 
221 
222 
223 
224 
225 
226 
227 
228 
229 
230 
231 
232 
233 
234 
235 
236 
237 
238 
239 
240 
241 
242 
243 
244 
245 
246 
247 
248 
249 
250 
251 
252 
253 
254 
255 
256 
257 
258 
259 
260 
261 
262 
263 
264 
265 
266 
267 
268 
269 
270 
271 
272 
273 
274 
275 
276 
277 
278 
279 
280 
281 
282 
283 
284 
285 
286 



DASRC' 



SAVE. 



GO' 



DRTTA 



DRTEA. 



DRTTB 



LD 


A, DRTWRO 


OUT 


(DRTCA), A 


LD 


A, ESCRES 


OUT 


(DRTCA), A 


LD 


A, (DRTFLO) 


SET 


0, A 


LD 


(DRTFLG), A 


RET 




CALL 


SAVE 


LD 


A, DRTWRO 


OUT 


(DRTCA), A 


LD 


A, SRCRES 


OUT 


(DRTCA), A 


LD 


A, (DRTFLG) 


SET 


1, A 


LD 


(DRTFLG), A 


RET 





>CH. B SPECIAL RX COND. 



MATHEWS SAVE REGISTER ROUTINE 



SP 



EX 


(SP), HL 


PUSH 


DE 


PUSH 


BC 


PUSH 


AF 


PUSH 


IX 


PUSH 


IY 


CALL 


GO 


POP 


IY 


POP 


IX 


POP 


AF 


POP 


BC 


POP 


DE 


POP 


HL 


EI 




RET I 





HL 
DE 
BC 
AF 
IX 
IY 
PC 



JP 



(HL) 



CONSTANTS 



, CHAN. RESET 



i CHAN. CHARACS. 



DEFB DRTWRO 

DEFB CHRES 

DEFB DRTWR1 

DEFB RXIAP+TXI+EXTI 

DEFB DRTWR4 , MODE 

DEFB X 1 6+ST0P2+EVEN+P AR I T Y 

DEFB DRTWR5 , TX PARAMS. 

DEFB DTR+TX7+TXEN+RTS 

DEFB DRTWR3 i RX PARAMS. 

DEFB RX7+RXEN 

EQU * 



DEFB DRTWRO ; CHAN. RESET 

DEFB CHRES 

DEFB DRTWR1 ; CHAN. CHARACS. 

DEFB RXIAP+DRTSAV+TXI+EX7I 

DEFB DRTWR2 , VECTOR REG 

DEFB DRTVEC. AND. 255 

DEFB DRTWR4 ; MODE 

DEFB X16+ST0P2+EVEN+PARITY 

DEFB DRTWR5 ; TX PARAMS. 

DEFB DTR+TX7+TXEN+RTS 

DEFB DRTWR3 i RX PARAMS. 

DEFB RX7+RXEN 
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TEST DART 
OBJ CODE M STMT SOURCE STATEMENT 



1 26 


28 


0127 


00 


0128 


2B 


0129 


EE 


012A 


06 


012B 


OE 


012C 


1C 


01 2D 


C2 


012E 


ID 


012F 


C2 


0130 


IE 


0131 


C2 


3 32 


16 


0133 


00 


0134 


17 


0135 


06 


0136 


18 


0137 


00 


0138 


19 


0139 


06 


Oj3A 


1A 


013B 


00 


013C 


IB 


01 3D 


06 


'.M3E 


01 


013F 


FO 


0140 


OA 


0141 


06 


0142 


OB 


0143 


06 


0144 


OC 


0145 


06 



2000 
2000 
2040 
2041 
2043 



287 


DRTEB 


EQU 


$ 


288 








239 


CLST- 






290 




DEFB 


28H 


291 




DEFB 


OOOOOOOOB 


292 




DEFB 


2BH 


293 




DEFB 


11101110B 


294 




DEFB 


6 


295 




DEFB 


00001 110B 


296 




DEFB 


1CH 


297 




DEFB 


11 00001 OB 


298 




DEFB 


1DH 


299 




DEFB 


11 00001 OB 


300 




DEFB 


1EH 


301 




DEFB 


11 00001 OB 


302 




DEFB 


16H 


303 




DEFB 





304 




DEFB 


17H 


305 




DEFB 


CIOCNT 


306 




DEFB 


18H 


307 




DEFB 





308 




DEFB 


19H 


309 




DEFB 


CIOCNT 


310 




DEFB 


1AH 


311 




DEFB 





312 




DEFB 


1BH 


313 




DEFB 


CIOCNT 


314 




DEFB 


1 


315 




DEFB 


11110000B 


316 




DEFB 


10 


317 




DEFB 


0000011 OB 


318 




DEFB 


11 


319 




DEFB 


000001 10B 


320 




DEFB 


12 


321 




DEFB 


0000011 OB 


322 


CEND: 


EQU 


* 


323 


*£ 






324 








325 


; , 


DATA 


AREA 


326 








327 




ORG 


RAM 


328 


BUFFER: 


DEFS 


64 


329 


DRTFLG: 


DEFS 


1 


330 


BUFPTR- 


DEFS 


2 


331 




DEFS 


64 


332 


STAK: 


EQU 


* 


333 








334 




END 





ASM 5. 9 

>PORT B MODE 

; DATA DIRECTION 

i " " PORT C 

iCTl MODE 

;CT2 MODE 

; CT3 MODE 

i CTi TC MSB 

, LSB 

* CI 2 TC MSB 

; LSB 

;C13 TC MSB 

; LSB 

; MASTER CONFIO. REG. 

/CTi TRIGGER 

, CT2 TRIGGER 

; C7 3 TRIGGER 



, STACK AREA 
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Interfacing 
8500 Peripherals 
To The Z80 




Zilog 



Application Brief 



December 1980 



INTRODUCTION There are several differences between the 
8500 devices and the Z80 family peripheral 
devices, including interrupt handling, reset 
to the device, and daisy-chain control. 

This application brief describes the hardware 
interface requirements and interrupt struc- 



ture of the 8500 series peripherals in Z80 
systems. The 8500 peripherals are genera I - 
interface versions of the Z-BUS counterparts 
and are designed to interface to nonmulti- 
plexed buses (such as In a Z80 system), 
instead of multiplexed buses (such as in the 
Z8000). 



CPU HARDWARE The hardware interface consists of three 
INTERFACING basic groups of signals: the data bus, 

control and selection lines, and the inter- 
rupt control lines. Following is a table of 
the general interface signals used by the 
CPU. Additional information can be found in 
the peripherals' separate data sheets. 

DATA BUS 

Dq-D>7 Data bus, bidirectional, 3-state. 
This bus is used to transfer data 
between the CPU and the peripheral 
device. 



A 0" A n 



CE 



CONTROL SIGNALS 

Address select lines (optional). 
These lines are normally used to 
select the port and /or control 
registers. 

Chip Enable. CE should be gated 
with I0RQ or MREQ to prevent spur- 
ious chip selects during other 
machine cycles. 



RD* Read. RD activates chip-read cir- 
cuitry and gates data from chip onto 
data bus (to be read by the CPU). 

WR* Write. WR is used to strobe data 
from bus into chip. 

INTERRUPT CONTROL 

I NTACK Interrupt acknowledge signal from 

CPU. This replaces the Ml and T0RQ 
generated by the Z80 CPU for inter- 
rupt acknowledge. It is used in 
conjunction with ^D" to gate the 
interrupt vector onto the data bus. 

INT, I El Interrupt Request, Interrupt Enable 
IE0 Input and Interrupt Enable Output. 
These lines are functionally equiv- 
alent to those in the Z80 peripheral 
products. INT is open-drain, active 
Low output. 



*Chfp reset is accomplished by activating RD 
and WR simultaneously. 



INTERRUPT Understanding the 8500 interrupt operation 
OPERATION requires basic operational knowledge of the 
Interrupt Pending (IP) and Interrupt Under 
Service (IUS) bits in relation to the daisy 
chain. IP is set in the SI0 by an interrupt 
condition, such as the transmit buffer going 
empty, and is used with IUS to control the 
TNT signal. IP is not set while the CPU is 
executing an Interrupt acknowledge cycle. 
Thus, 



IP = INT * VREAD 



The IP latch Is cleared either by a software 



command to the device or by an implicit 
action generated by the interrupt service 
routine. The implicit action may be 
triggered by the CPU reading or writing a 
register In the device. For example, on a 
serial receive device like the SI 0, IP may be 
reset when the CPU reads the character from 
the receive buffer that caused the interrupt. 
This removes the interrupt condition, allow- 
ing other interrupts to occur. 

The Interrupt Under Service (IUS) latch is 
used to designate the interrupt that is 
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currently being serviced, I US is set when 
the device receives an interrupt acknowledge 
from the CPU while IEI is High and IP is set. 
If IEI is Low, the device is prevented from 
setting the I US latch and thus cannot issue a 
vector. In this way, the daisy chain can 
establish relative priority among peripheral 
devices. I US is cleared on the 8500 devices 
by an explicit software command. 

The daisy chain used in the Z80 peripherals 
is referred to as an IP and I US daisy chain, 
because the IP and I US bits control the IE0 
pin and the lower portion of the chain. If 
IP is set, IE0 can be Low even if another 
peripheral has an interrupt under service. 
When the CPU executes an RETI instruction 
(ED-4D opcode), the peripheral monitors the 
bus and resets I US. When the CPU reads the 
"ED" part of RETI, peripherals with IP set 
and IEI High bring IE0 High momentarily. This 
enables the device in the chain with I US set 
to clear its I US latch when the "4D" byte is 
read by the CPU. (I US for a device is not 
cleared unless IEI is High and the "ED-4D" 
instruction is decoded. This allows more 
than one device to have I US set so that 
nested interrupts can be implemented.) 

On the 8500 series devices, IP is used to 
control the daisy chain only during the 
interrupt acknowledge cycle. Under normal 

WAIT FOR CPU 

INTERRUPT ACKNOWLEDGE 

CYCLE 

INTERRUPT 
CONDITION , |p 

SET 




conditions, only I US is required to control 
the state of the I EO pin. Therefore, the 
daisy chain used in 8500 devices is referred 
to as an I US daisy chain. Since IP is not a 
part of the daisy chain, there is no "ED" 
decoding pulling IE0 High when IP is set. To 
allow more control over the daisy chain, the 
8500 devices have a "Disable Lower Chain" 
(DLC) software command that unconditionally 
brings IE0 Low. This can be used to deacti- 
vate parts of the daisy chain selectively, 
regardless of interrupt status. Figure 1 
shows the functions of IP and I US and the 
truth tables for each. 

A unique feature of the 8500 devices is the 
I NTACK pin. This pin acknowledges a CPU 
interrupt service cycle to the peripheral, 
allowing the peripheral to gate its vector 
onto the data bus. On the Z80 peripherals, 
interrupt acknowledge cycles from th e CPU 
consist of a special M1 cycle where I0RQ is 
activated instead of MREQ. This limits the 
control of devices in systems using a 
processor other than the Z80. As a result, a 
simpler implementation has been devised, 
which uses additional logic to accommodate a 
wider variety of processors. Figure 2 shows 
a circuit that generates I NTACK for the 8500 
devices In addition to wait states. Figure 3 
shows the timing for I NTACK and wait gener- 
ation. 



RETURN TO 
IUS \ MAIN PROGRAM 

[CLEARED] *► 



a) State diagram of 8500 devices during interrupt cycle 



IEI IP IUS IEO 



IEI IP IUS IEO 



b) 8500 device during idle state 



c) 8500 device during INTACK cycle. 



Figure 1. 8500 Device Interrupt-Processing Sequence 




^o INTACK 



WAIT (FROM PERIPHERAL) 



Figure 2. INTACK and WAIT Generation for 8500 Peripherals 
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NOTE. WAIT 'is assumed to be High. 



Figure 3. Timing for 8500 Peripherals During Interrupt Acknowledge Without Z80 Peripheral Logic 



On long daisy chains, wait states may be 
necessary to allow the I El and IE0 lines time 
to stabilize, thus avoiding conflict between 
devices and preventing I US or IP from chang- 
ing erroneously. Because of the IP and I US 
configurations, the daisy chain used in Z80 
peripherals needs to stablilize during the 
interrupt acknowledge and RET I operations. 



However, on the 8500 devices, the daisy chain 
is I US and wait states are generated for the 
INTACK cycle only, not for the return cycle. 
(There is no "ED-4D" decode.) As a result, 
hardware interfacing is greatly simplified 
and timing is less complicated than on the 
Z80 peripherals. 



SOFTWARE There are several options available for 
CONSIDERATIONS servicing interrupts on the 8500 devices. 
Since the vector register (or IP register) 
can be read at any time, the software can 
emulate the Z80 CPU interrupt response 
easily. The interrupt vector reflects the 
interrupt status condition, even if the 



peripheral is programmed to return a vector 
that does not reflect the status change (SAV 
or VIS not set). This allows a simple soft- 
ware routine to emulate the Z80 vector 
response operation, as shown in the code of 
Figure 4. 



Loc. ObJ Coda M. Stmt Sourc. Statement 



0000 


3E00 


0002 


D3E0 


0004 


DBE0 


0006 


3C 


0007 


C8 


0008 


E60E 


000A 


5F 


000B 


1600 


000D 


211600 


0010 


19 


0011 


7E 


0012 


23 


0013 


66 


0014 


6F 


0015 


E9 


0016 


0010 


0018 


0011 


001A 


0012 


001 C 


0013 


001E 


0014 


0020 


0015 


0022 


0016 


0024 


0017 



36 VECTAB: 



This routine emulates the Z80 vector Interrupt 
operation by reading the device Interrupt vector, 
forming an address from a vector table, and exe- 
cuting an Indirect jump to the interrupt service 
routine. 



ID 


A.CIVREG 


CURRENT INT. VECTOR REG 


OUT 


(CTRL), A 


WRITE REG. PTR. 


IN 


A, (CTRL) 


READ VECTOR REG. 


INC 


A 


VALID VECTOR? 


RET 


Z 


NO INTERRUPT - RETURN 


AND 


00001 11 0B 


MASK OTHER BITS 


LD 


E,A 


FORM INDEX VALUE 


LD 


0,0 




LD 


HL, VECTAB 


ADD VECTOR TABLE ADDR 


ADD 


HL.DE 




LD 


A,(HL) 


GET LOW BYTE 


INC 


HL 




LD 


H,(HL) 


GET HIGH BYTE 


LD 


L,A 


PUT ROUTINE ADDR IN *HL 


JP 


(HL) 


GO TO ROUTINE ! 


DEFW 


INT1 




DEFW 


INT2 




DEFW 


INT3 




DEFW 


INT4 




DEFW 


INT5 




DEFW 


INT6 




DEFW 


INT7 




DEFW 


INT8 





Figure 4. Z80 Vector Interrupt Response Emulation by Software 
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Because the 8500 devices have considerable 
program flexibility, a Master Interrupt 
Enable (MIE or IE) bit in the control 
register determines the device response to 
the CPU. If MIE is not set, interrupts are 



not generated to the CPU and the device 
ignores any interrupt response from the CPU. 
This is used as a global enable and simpli- 
fies the programming of interrupts so that 
they can be easily changed on the fly. 



A SIMPLE The 8500 devices interface easily to the Z80 

Z80 SYSTEM CPU, providing a system of considerable 

flexibility. Figure 5 illustrates a simple 
system using the Z80 CPU and a Z8 536 CI O in a 
non interrupt environment. Since INTACK is 
not used, it is tied High and no additional 
logic is needed. Because the CIO can be used 
in a polled interrupt system, the INT pin is 
connected to the CPU. The Z80 should not be 
programmed for Interrupt Mode 2, because the 
vector from the CIO is never sent to the CPU. 
Instead, the CPU can be set for Interrupt 
Mode 1, and a global interrupt routine that 
reads the vector register from the CIO can 
determine which routine to go to when an 
interrupt occurs, as previously illustrated 
in Figure 4. 



Z80 
CPU 



| osc |-i > 



+ 



H>~ 



5> 



j^ INTACK 
D0-D7 



8530 
CIO 



Figure 5. Non-Interrupt CPU Interface 



Z80 

PERIPHERAL? 
WITH 8500 
PERIPHERALS 



A Z80 system using a combination of Z80 
family peripherals and 8500- type peripherals 
is easily constructed, as shown in Figure 6. 
There is no placement restriction on the 8500 
devices within the daisy chain, but it is 
recommended that they be near the beginning 



of the chain in order to minimize propagation 
delays during the "ED-AD" decoding. The 8500 
devices do not decode the "ED" during an 
opcode fetch cycle, so IE0 will not change 
state during this time. 



Z80 

CPU 



MREQ 
IORQ 
WAIT 



8'' 



WAIT& 

INTACK 

GENERATION 

LOGIC 



CLK I 

OSC -l_t>^LK_ 



I— I IORQ 

D0-D7 i «i int 



rlioRQ 

D0-D7 RD Ml INT 



iEi 

Z80-XXX 

IORQ 
D0-D7 RD Ml JNT 



RESET 
CIRCUIT 



NOTE. Z80 DMA uses the WR line also. 



Figure 6. A Z80 System Using 8500 Devices and Z80 Peripherals 



Figure 7 is a diagram of the logic repre- 
sented by the WAIT a nd INTACK logic box in 
Figure 6. The WAIT'signal is OR-wired to the 
output of each peripheral device (if used). 
The RD and WR signals only go to the 8500 



device. The Z80 peripherals are w ired to the 
Z80 as usual. The timing for the INTACK and 
WAIT generation logic is illustrated in 
Figure 8. 
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WR 

RESET 

RD 



7*> 



IORQ 



E«l = 1 « I I 

■-WD :; 




TO 8500 
PERIPHERALS 



*Wait from peripheral devices 



Figure 7. WAIT and INTACK Generation Logic 




Figure 8. Timing for 8500 and Z80 Peripherals During Interrupt Acknowledge 
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INTRODUCTION When an external clock is not provided in a 
Z80-based system, it is often necessary to 
generate a bit-rate clock for serial devices. 
The most efficient way to accomplish this is 
to use a programmable counter that can change 
the bit-rate clock under CPU control. In 
this example, the Z8536 Counter/Timer I/O 
device (CIO) was chosen to generate the bit- 
rate clocks for a Z80-based statistical mul- 



tiplexor project that used a Z80 SIO and a 
Z80 DART. 

This application brief describes the use of 
the Z8536 CIO device in a Z80-based system 
for generating the bit-rate clocks for asyn- 
chronous communications. The Z8536 CIO con- 
tains the circuitry necessary to generate the 
clock pulses required by asynchronous com- 
munication devices. 



HARDWARE The Z8536 CIO is housed in a 40-pin package 
and contains both system bus interface and 
I/O port connections. The three 16-bit coun- 
ters can be programmed to output a pulse, 
square wave, or one-shot waveform on the 
timer's corresponding output pin. Three bits 
of the output ports (two from Port B and one 
from Port C) are used as the counter/timer 
outputs and provide the bit-rate pulses used 
In this appl icatlon. 

Interfacing the CIO to the Z80 CPU requires 
eight bidirectional data lines and five con- 
trol lines. The data lines are used to 
transfer register address and data to or from 
the CIO via the RD, WR, CE, and address con- 
trol lines. Two address lines (Aq and A^) 
select the port the CPU is accessing. Table 
1 shows the port selected by the address 
bits. 

Table 1* Port Addressing for the CIO 



Address Line 


A 1 


A o 


Port C 

Port B 

Port A 

CTRL 





1 
1 




1 



1 



The control port (CTRL) is used for control 
register selection and parameter transfer. 
To select a particular register, a Register 
Pointer is written to the CTRL port and the 
data is written into or read from the 
register. 

The CIO contains a state machine that con- 
trols the CPU interface. Upon power-up, the 



CIO is placed in a reset state and remains 
there until cleared by the program. Reset can 
also be initiated by issuing a command to 
Register with bit set or by a hardware 
condition (RD and WB simultaneously active). 
The reset state Is described In detail in the 
programming section. Once the reset state Is 
cleared, the CIO Is placed In state 0, in 
which the control registers can be accessed 
by writing a Register Pointer to the CIO 
control port. This places the CIO in state 
1, after which the next CPU access (read or 
write register data) causes the CIO to revert 
to state 0. The last register addressed may 
be accessed simply by reading the CIO control 
port. It should be noted that the Register 
Pointer can be written only while In state 0. 
Also, data can be written to a control reg- 
ister only after a Register Pointer has been 
written. Figure 1 shows the state diagram 
for the CIO. 



HARDWARE 

OR 

SOFTWARE 

RESET 



(BIT = 1) 

Figure 1. State Diagram for Z8536 CIO 



The RD and WR control lines determine the 
data path direction into or out of the CIO. 
When activated simultaneously, they also 
perform the device's reset function. Figure 
2 illustrates how the reset function can be 
implemented using external circuitry. 
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Since in terrup ts are not used in this appli- 
cation, I NTACK is tied High to prevent 
spurious interrupt operation of the CIO due 
to noise. 

Each counter/timer uses one or more bits on 
one of the parallel ports to provide for 
counter input and counter/timer output. Table 
2 shows which output port bits correspond to 
particular counter/timer inputs and outputs. 

The outputs of the counter/timers (PB4, PBO, 
and PCO) are fed to the rest of the circuitry 
to supply the serial clock pulses. 



Table 2. 
Externa I 



Counter/Timer 
Interface Bits 



Function 


C/T1 


C/T2 


C/T3 


C/T Output 
Counter Input 
Trigger Input 
Gate Input 


PB4* 
PB5 
PB6 
PB7 


PBO 
PB1 
PB2 
PB3 


PCO 
PC1 
PC2 
PC3 



LS08 




FROM 

Z80 { RESET 
CPU 



Figure 2. RESET Interface to the Z8536 



*PB4 = Port B, bit 4 



The last hardware consideration involves the 
clock input, PCLK. Since the Z8536 does not 
need to be synchronized with the CPU clock, 
PCLK can come from any source so long as it 
meets the timing and interface requirements. 
In fact, PCLK can come from a source external 
to the system if desired. Once inside the 
device, PCLK is divided by two before it is 
sent to the counter/timer circuits. There 
is no other prescaling done and the resulting 
clock is fed to the 16-bit counters. 



PROGRAMMING Once the hardware has been defined, the func- 
tional operation and configuration of the 
Z8536 are determined entirely by the software 
programming. Several considerations concern- 
ing initialization must be made when using 
the CIO. When the device receives a reset 
from either hardware or a software command, 
the reset state must be removed before any 
data can be written to the CIO. To clear the 
reset state, the user writes to register 
with bit cleared. Once the internal reset 
latch is cleared, the programmer can initial- 
ize the CIO and begin normal operations. The 
program listed in the appendix shows a reset 
sequence that brings the CIO to state even 
if the previous state is undefined. 

The configuration of the CIO defines the 
general operating characteristics of the 
device with respect to its internal func- 
tions. The Port Mode Specification register 
sets to output those bits in Port B that are 
used for the counter/timer outputs. In this 
example, Bit mode is used on Ports B and C to 
output the counter/timer pulses. 

The Counter/Timer mode, time constant values, 
and trigger commands are the last parameters 
to be set. Finally, the Master Configuration 
Control register is set to enable Port B, all 
the counter/timers, and Port C (Port C is 
enabled along with the counter/timers). The 
Counter/Timer mode is programmed for contin- 
uous cycle square wave with external output 
enabled. The square-wave cycle time is two 
times the programmed time constant, which 
must be taken into account when programming 
time constant values. The downcounters in 
the CIO are 16-bit counters that are decre- 
mented by one for each internal clock cycle. 
The internal clock cycle is the PCLK cycle 
divided by two, so the time constant value is 
determ i ned by the f o I I ow i ng f ormu I a : 



Time Constant= PCLK / (4 * Output Frequency) 

PCLK is divided by four in the formula be- 
cause it is divided by two inside the CIO 
before being fed into the downcounter and by 
two again because a square wave cycle is two 
times the time constant value. Substituting 
the baud rate and a multiplier of 16 for the 
output frequency, the formula reduces to a 
simple time constant formula. 

TC = PCLK / (4 * 16 * Baud Rate) 

With a 3*6864 mh z PCLK input and a desired 
9600 baud rate, the formula simplifies to: 

TC = 3,686,400 / (4 * 16 * 9600) 
= 57600 / 9600 
= 6 

Other 16X baud rates may be generated by 
using the above formula in a general form. 

TC = 57600 / Baud Rate 

The user must exercise caution when choosing 
values for the PCLK and baud rates since they 
must result in nearly integral time constant 
values. For example, a 2.4576 MHz clock 
input with 9600 baud and a 16X clock output 
give a time constant value of 4. Greater 
flexibility is available for selecting time 
constant values because the SI0 does not 
require a square wave input when programmed 
for 16X, 32X, or 64X clock inputs. Pulses 
may be used with the SIO provided the user 
adheres to the SIO timing requirements. 

The last operation performed on the CIO is a 
trigger command to "kick it off," This also 
includes setting the gate command bit in the 
CounterAimer Command and Status registers, 
which allows the clock pulses to toggle the 
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downcounter. The trigger command bit loads an 
initial value into the downcounter and begins 
operation of the counter/timer circuitry. 
Once triggered, the counter/timer runs con- 
tinuously, performing automatic reloads to 



the downcounter after it reaches zero (term- 
inal) count. At this time, the CIO is fin- 
ished being programmed and the user has 
three clean square waveforms at the output 
pins. 



CONCLUSION The designer should find the Z8536 CIO a 
versatile and cost-effective component to 
satisfy his or her system needs. Coupled 
with other Zilog components, the Z8536 archi- 
tecture enhances the performance of any Z80 
system by providing the essential timing, I/O 
functions, and interrupt control functions 
necessary for efficient system operation. 



The Z8536 CIO was chosen after considering 
device count, performance, and ease of use. 
Alternatives to the CIO include discrete 
(TTL) hardware counters and gates, external 
clock sources, or the Z80 CTC. These methods 
are generally too parts- intensive, and power 
consumption is therefore higher. For appli- 
cations where two 8-bit ports and three 
counter/timers are needed, the CIO proves to 
be the ideal component. 



APPENDIX Following is a listing of a test program 

written for the Z80 CPU. This program simply 
Initializes the CIO and then loops until 



LOC 



TEST. CIO 
OBJ CODE M STMT SOURCE STATEMENT 



stopped, with the CIO continuously providing 
pulses. All three counter/timers are used to 
generate square waves corresponding to a 16X 
9600 baud clock. 



ASM 5. 9 



0000 



0000 
0003 



0006 



314020 
CD0800 



18FE 



0008 


DBOB 


OOOA 


3E00 


000C 


D30B 


000E 


DBOB 


0010 


3E00 


0012 


D30B 


0014 


3E01 


0016 


D30B 


0018 


3E00 


001A 


D30B 


001C 


212600 


001F 


0620 


0021 


OEOB 


0023 


EDB3 


0025 


C9 



1 

2 
3 
4 
5 
6 
7 
8 
9 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 
27 
28 
29 
30 
31 
32 
33 
34 
35 
36 
37 
38 
39 
40 
41 
42 
43 
44 
45 
46 
47 
48 



C1D 



CIO TEST PROGRAM 
01-07-81 /MDP 



INITIAL CREATION 



CIOC: 

CIOB: 

CICtt: 

CIOCTL: 

BAUD: 

RATE: 

CIOCNT: 

RAM 

RAMSIZ 

*E 



BEGIN: 



INIT: 
CIOINI: 



THIS PROGRAM INITIALIZES THE THREE COUNTER 
TIMERS IN THE Z8536 CIO TO GENERATE SQUARE 
WAVES, THEN LOOPS FOREVER. 



PROGRAM EQUATES 



EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 



8 

CIOC+1 

CIOC+2 

CIOC+3 

9600 

BAUD/ 100 

576/RATE 

2000H 

1000H 



»** MAIN PROGRAM ♦♦* 
ORG 



LD 
CALL 



JR 



IN 

LD 

OUT 

IN 

LD 

OUT 

LD 

OUT 

LD 

OUT 

LD 

LD 

LD 

OTIR 

RET 



SP,STAK 
INIT 



A, (CIOCTL) 
A, 

(CIOCTL), A 
A, (CIOCTL) 
A, 

(CIOCTL), A 
A, 1 

(CIOCTL), A 
A, 

(CIOCTL), A 
HL, CLST 
B, CEND-CLST 
C, CIOCTL 



CIO PORT C 
CIO PORT B 
CIO PORT A 
CIO CTRL PORT 
ASYNC BAUD RATE 



iRAM START ADDR 
;RAM SIZE 



INIT SP. 
INIT DEVICES 



;LOOP FOREVER 



INSURE STATE 

REG OR RESET 

WRITE PTR OR CLEAR RESET 

STATE O 

REG 

WRITE PTR 

WRITE RESET 

; CLEAR RESET 

; INIT CIO 



*E 
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LOC 



TEST. CIO 
OBJ CODE M STMT SOURCE STATEMENT 



ASM 5. 9 







49 ; ; 


CONSTANTS 










50 














51 CLST: 








0026 


28 


52 


DEFB 


28H 


iPORT B MODE 


0027 


00 


53 


DEFB 


OOOOOOOOB 






0028 


2B 


54 


DEFB 


2BH 


;PORT B DIRECTION 


0029 


EE 


55 


DEFB 


lliOlllOB 






002A 


06 


56 


DEFB 


06H 


iPORT C DIRECTION 


002B 


FE 


57 


DEFB 


UlllllOB 






002C 


1C 


58 


DEFB 


1CH 


iCll 


MODE 


002D 


C2 


59 


DEFB 


11 00001 OB 






002E 


ID 


60 


DEFB 


1DH 


;CT2 


MODE 


002F 


C2 


61 


DEFB 


11 00001 OB 






0030 


IE 


62 


DEFB 


1EH 


;CT3 


MODE 


0031 


C2 


63 


DEFB 


11 00001 OB 






0032 


16 


64 


DEFB 


16H 


; CT1 


TC MSB 


0033 


00 


65 


DEFB 









0034 


17 


66 


DEFB 


17H 


; 


LSB 


0035 


06 


67 


DEFB 


CIOCNT 






0036 


18 


68 


DEFB 


18H 


i CT2 


TC MSB 


0037 


00 


69 


DEFB 









0038 


19 


70 


DEFB 


19H 


; 


LSB 


0039 


06 


71 


DEFB 


CIOCNT 






003A 


1A 


72 


DEFB 


1AH 


;CT3 


TC MSB 


003B 


00 


73 


DEFB 









003C 


IB 


74 


DEFB 


1BH 


i 


LSB 


003D 


06 


75 


DEFB 


CIOCNT 






003E 


01 


76 


DEFB 


1 


i MASTER CONFIG. REG 


003F 


FO 


77 


DEFB 


HUOOOOB 






0040 


OA 


78 


DEFB 


OAH 


iCTl 


TRIGGER 


0041 


06 


79 


DEFB 


0000011 OB 






0042 


OB 


80 


DEFB 


OBH 


i CT2 


TRIGGER 


0043 


06 


81 


DEFB 


0000011 OB 






0044 


OC 


82 


DEFB 


OCH 


i CT3 


TRIGGER 


0045 


06 


83 


DEFB 


0000011 OB 










84 CEND: EQU 


* 










85 














86 ; ; 


DATA 


AREA 










87 










2000 




88 


ORG 


RAM 






2000 




89 


DEFS 


64 


; STACK AREA 






90 STAK: EQU 


* 










91 














92 


END 
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INTRODUCTION In many computer systems, an accurate time 
base Is needed so that critically timed 
events do not go awry. Use of a counter or 
timer to monitor time-dependent activities Is 
essential In such systems. In an Jnterrupt- 
drlven system, the Z80 CTC can provide 
regular program time Intervals, Single-event 



counts or single-event time delays can also 
be implemented under program control. This 
application note describes both continuous 
1 1 me- I nterval operations and single- interval 
count operations using the Z8 CTC In a Z8 
system. 



HARDWARE In the example used here, the hardware con- 

CONFIGURATION sIs1 " s of a z 8 cp U with 4K bytes of RAM, 4K 

bytes of ROM, a Z8 0A SIO, and a Z8 0A CTC. 

There are two external Inputs to the CTC: one 

Is derived from the ac power line to provide 



60Hz pulses; the other Is connected to a 
transmit clock line on the SIO, One of the 
counter/timer outputs is connected to the SIO 
transmit and receive clock input, as shown In 
Figure 1, 















4K 
RAM 








4K 
ROM 






Z80A 
CPU 

INT 
CLK 










ADDRESS 


16 




















DATA '& 












CONTROL / 7 














/ 






















+ 5V 


zcn*o 2 

CLKrTRIG3 
CTC 

CLKfTRIG 1 
CLK INT 




RxTxCA 

TxCB 

SIO 

RxCB 

CLK INT 










► 4.71 


< 














I 






























OSCILLATOR 




















RS-232C 
INTERFACE 










< 

60 H 
PULi 


► 

z TTL 

5ES 




i 




i 







Figure 1. ZBOA System Block Diagram 
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The Z80 CTC Is designed for easy interface to 
the Z80 CPU. An 8-bit bidirectional data bus 
is used to transfer information bet ween th e 
CTC and CPU, The control lines, RD, IORQ, M1, 
and CE, determine what da ta i s being trans- 
ferred and when, M1 and IORQ are used during 
the interrupt acknowledge cycle to allow the 
CTC to p resen t Its 8-bit interrupt vector to 
the CPU, IORQ is also used in conjunction 
with 0*E to enab le transfers between the CTC 
and the CPU, RD is used to control the 
direction of data flow between the CTC and 
the CPU, The channel select lines (CSq and 
CS^) are connected to the lowest two bits of 
the address bus and are used to access one of 
the four counter/timer channels. Table 1 
shows the relationships between the CS pins 
and the counter/timer channels. 



Table 1. Channel Select Values 



cs 1 


cs 


CA Channel 





1 

1 




1 



1 


Channel 
Channel 1 
Channel 2 
Cnannei 3 



The CTC system clock input requirements are 
similar to those of the Z80 CPU. For both, 
the system clock input Low level should be no 
greater then 0.45 V, the High level should be 
no less than V QC -0.6 V, and the clock rise 
and fall times should be less than 30 ns. A 
clock-driver device that meets these require- 
ments, such as the HH-3006-A 1 , works well 



with the CtC, Several devices can be con- 
nected to the driver, but the user should be 
careful not to overload the driver. The capa- 
citance of the clock input to the CTC (20 pF) 
should be noted as this may affect the system 
clock rise and fal I times. 

Interrupt control logic within the CTC is 
used to initiate interrupts and to control 
the interrupt acknowledge cycle generated by 
the CPU. An interrupt is generated by the CTC 
when one of the counter/timer down counters 
reaches terminal count (0) and IE I Is High. 
I El and I E0 a I low the CTC to operate within 
the Z80 interrupt daisy chain and to connect 
to the next higher-priority and next 
lower- priority devices in the chain, respec- 
tively. If there is no h igher-priority de- 
vice, I El is tied to +5 V. 

The CTC internally prioritizes each counter/ 
timer with respect to interrupt generation. 
This maximizes performance by resolving con- 
tention between channels should two or more 
interrupt conditions occur simultaneously. 
Table 2 shows the relative priority levels of 
each counter/timer within the CTC. 

Table 2. CTC Channel Interrupt Priority 



Priority 


Channel 


Highest 
Lowest 



1 

2 
3 



CTC MODES There are two basic modes under which the CTC 

can operate: Timer mode and Counter mode. 
Each mode has certain programmable character- 



istics that enable the CTC to be used in a 
wide variety of applications. 



TIMER MODE A typical use of the CTC in Timer mode is to 

provide regular, fixed- interval interrupts to 
the CPU used as a time-base reference to 
allocate the processor resources efficiently. 
For example, a multitasking system might have 
the processor execute a task for a given 
length of time and then interrupt execution 
of the program at one-second intervals to 
scan the task queue for higher-priority 
tasks. This system time interval can be pro- 
vided by the CTC in Timer mode. In Timer 
mode, the CTC downcounter is decremented by 
the output of the prescaler, which is toggled 
by the system clock input. The prescaler has 
a programmable value of 16 or 256, depending 
on the condition of bit 5 in the channel 
control word (CCW). Thus, with a 4 MHz system 
clock fed into the CTC, a timer resolution of 
4us (prescaler count of 16) or 64ms (count of 
256) is possible. 

In the example shown, the interrupt interval 
is set to 8.33 ms, which Is provided by the 
CTC with a 3.6864 MHz input clock, 256 pre- 
scaler value, and a time constant value of 
120. The CTC interrupt service routine uses a 
software count of 120 to maintain a one- 
second system time interval. Each time the 
service routine is executed, the software 
count is decremented by 1. When the count 
reaches 0, a flag is set and the program 
pursues an appropriate course of action. 
Figure 2 shows the initialization and inter- 
rupt service routine coding for a CTC channel 
using the Timer mode. 



Another use of CTC Timer mode operation is to 
implement a nonretr iggerabl e one-shot using 
external circuitry. The digital approach to 
the one-shot provides a programmable time 
delay under CPU control and provides greater 
noise immunity than the more common analog 
delay circuits provide. Figure 3 shows a 
circuit that uses part of a 74LS02 package in 
addition to one CTC channel. 



The trigger waveform should be positive-going 
and should meet the CTC setup time for the 
CLK/TRIG input. Also, the trigger High level 
time should be less than the CTC delay time 
in order to prevent the two 74LS02s from 
latching in the triggered state. An addi- 
tional gate can be added to initialize the 
74LS02 flip-flop to a defined state when the 
system is reset or else the software can 
pulse the timer output to set the flip-flop, 
as is done in this case. A third use of the 
Timer mode is to provide a bit rate clock for 
a serial transceiver device, such as the Z80 
SI0. The SI0 can accept a 1x, 16x, 32x, or 
64x bit rate clock input from an external 
source, and with a 16x, 32x, or 64x multi- 
plier, the SI0 can accept a pulse waveform 
input for the bit rate clocks, as long as the 
pulses meet the rise, fall, and hold time 
requirements of the SI0. The CTC meets these 
requirements and can be connected directly to 
the SIO to provide the necessary bit rate 
clocks. Figure 4 shows the code needed to 
generate a bit rate clock for the SIO. 



^A clock driver by Hybrid House, 1615 Remuda La., San Jose, CA 95112. 
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With a 1x bit rate clock programmed Into the value should be set to half the baud rate 

SIO, a square-wave Input must be supplied. value, since the CTC output Is divided In 

This can be done by adding a flip-flop be- half by the flip-flop, 
tween the CTC and the SIO. The time constant 



C START ) 




v 


INITIALIZE CPU 


ir 


| INITIALIZE CTC 




u 




SETUP 
SOFTWARE COUNT 




\ 


' 




SETUP DISPLAY 




1 


r 




| ENABLE INTERRUPTS 








1 


' 


LOOP 









Q ENTER ^ 



SAVE REGISTERS 



DECREMENT 
SOFTWARE COUNT 




RESET 
SOFTWARE COUNT 



SWITCH 
DISPLAY STATE 



( EXiT ) 



a) Main Program 



b) Interrupt Service Routine 



TRIGGER 
INPUT 



Figure 2, Software for CTC Timer Mode Operation 

~i r 




,_r 



Figure 3. Monostable Multivibrator Using the Z80 CTC 
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TEST CTCO 
OBJ CODE M STMT SOURCE STATEMENT 



CTC TEST PROGRAM 



CO GO 
COCO 



OOIO 



0025 



C31800 



OOIO 


4000 


0012 


3D00 


0014 


3D00 


Or. 16 


3D00 


00 IB 


314020 


00 3 B 


ED5E 


(?0 1 D 


3E00 


00 1 F 


E047 


002 1 


CD2700 


00c 4 


FB 



i 8FE 



*.-27 


3EA7 


irj29 


D30C 


002B 


3E70 


002 D 


D30C 


0«/rF 


3E10 


001)1 


D30C 


0033 


AF 


0C3A 


324120 


O037 


3E78 


O039 


324020 


003C 


C9 



3 
4 
5 
6 
7 
3 
9 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 
27 
28 
29 
30 
31 
32 
33 
34 
35 
36 
37 
38 
39 
40 
41 
42 
43 
44 
45 
46 
47 
48 
49 
50 
51 
52 
53 
54 
55 
56 
57 
58 
59 
60 
61 
62 
63 
64 
65 
66 
67 
68 
69 
70 



CTCO- 

CTC1 

CTC2 

CTC3: 

LITE 

RAM' 

RAMSIZ 

TIME- 



CCW. 



*E 



I NTVEC 



EEGIN 



INIT- 



THIS PROGRAM USES THE CTC IN CONTINUOUS 
TIMER MODE THE CTC COUNTS SYSTEM CLOCK 
PULSES AND INTERRUPTS EVERY 120 PULSES, 
THEN DECREMENTS A COUNT, TWIN SWITCHES 
THE LED STATE WHEN THE COUNT REACHES ZERO 



PROGRAM EQUATES 



EGU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 



12 

CTC 0+1 

CTCO+2 

CTC0*3 

OEOH 

2000H 

1000H 

120 



> CIC PORT 
. CTC 1 PORT 
, CTC 2 PORT 
, CTC 3 PORT 
i L I OUT PORT 

> RAM START ADDR 

, COUNT VALUE 



CTC EQUATES 



EQU 


1 




INTEN- 


EQU 


80H 


CTRMODE 




EQU 


P256 


EQU 


20H 


RISEDG' 


EQU 


10H 


PSTRT- 


EQU 


8 


TCLOAD- 


EQU 


4 


RESET: 


EQU 


2 



40H 



*#* MAIN PROGRAM *•** 



ORG 
JP 

ORG 

DEFW 
DEFW 
DEFW 
DEFW 



LD 

IM 

LD 

LD 

CALL 

EI 




BEGIN 

* AND OFFFOH OR 10H 

ICTCO 
ICTC1 
ICTC2 
ICTC3 



SP, STAK 

2 

A, INTVEC/256 

I, A 

INIT 



JR 



, INIT SP 

, VECTOR INTERRUPT MODF 

, UPPER VECTOR BVE 

i INIT DEVICES 

, ALLOW INTERRUPTS 

, LOOP FOREVER 



LD 


A, INTEN+P256+TCL0AD+RESE1 +CCW 


OUT 


(CTCO). A 


, SET CTC MODE 


LD 


A, TIME 




OUT 


(CTCO). A 


; BET TIME CONSTANT 


LD 


A, I NTVEC AND 


11111000B 


OUT 


(CTCO), A 


; SET VECTOR VALUC 


XOR 


A 




LD 


(DISP), A 


, CL EAR DISPLAY BYT 


LD 


A, TIME 


i INIT TIMER VALUE 


LD 


(COUNT). A 




RET 







INTERRUPT SERVICE ROUTINE 
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LOC 



TEST. CTCO 
OBJ CODE M STMT SOURCE STATEMENT 



00 3D 


FB 


003E 


ED4D 


0040 


CD5A00 


0043 


3A4020 


0046 


3D 


0047 


324020 


004A 


CO 


U04B 


3E78 


004 D 


324020 


00*50 


3A4120 


0053 


2F-" 


0034 


324120 


O057 


D3E0 


0059 


C9 



00 5 A 


E3 


00 5B 


D5 


00 5C 


C5 


005D 


F5 


O05E 


CD6800 


OOo 1 


Fi 


0O62 


CI 


u063 


Dt 


0064 


El 


0^6 5 


FB 


0',<i>6 


ED4D 



>r^8 



2000 
2000 



2040 
204 1 



E9 



71 


ICTC1 






72 


ICTC2 






73 


ICTC3 






74 




EI 




75 




PETI 




76 








77 


I CTCO 






78 




CALL 


SAVE 


79 




LD 


A. (COUNT) 


80 




DEC 


A 


81 




LD 


(COUNT), A 


82 




RET 


NZ 


83 




LD 


A, TIME 


84 




LD 


(COUNT), A 


85 




LD 


A, (DISP) 


86 




CPL 




87 




LD 


(DISP), A 


88 




OUT 


(LITE)/ A 


89 




RET 




90 








91 




SAVE 


REGISTER ROU 


92 








93 


GAVE 






94 




EX 


< SP ) , HI- 


95 




PUSH 


DE 


96 




PUSH 


BC 


97 




PUSH 


AF 


98 




CALL 


GU 


99 




POP 


AF 


100 




POP 


BC 


101 




p p 


DE 


102 




POP 


HL 


103 




EI 




104 




RETI 




105 








106 


GO 






107 




UP 


< HL ) 


108 


*E 






109 








no 


, , 


DATA 


AREA 


111 








112 




ORG 


RAM 


113 




DEFS 


64 


114 


STAK 


EQU 


* 


115 


COUNT 


DEFS 


1 


116 


DISP. 


DEFS 


1 


117 








118 




END 





- DUMMY ROUTINES 



, SAVE REGISTERS 

■ CHANGE TIMER COUNT 



.EXIT IF NOT DONC" 

, EL&E, RESET TIMfP VALOI 



r Bl INK L1TES 



, STACK AREA 



, TIMER COUNT VALUE 
i LITE DISPLAY BYTE 



Q START ^ 



y 


r 




INITIZLIZE CTC 






\ 


' 




LOOP 











MAIN PROGRAM 



Figure 4, Software for CTC Bit Rate Generator 
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LOG 



TEST. CTC2 
OBJ CODE M STMT SOURCE STATEMENT 



0000 



0000 


3E07 


0002 


D30E 


0004 


3E03 


0006 


D30E 



18FE 



1 
2 
3 
4 
5 
6 
7 
S 
9 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 
27 
28 
29 
30 
31 
32 
33 
34 
35 
36 
37 
38 
39 
40 
41 
42 
43 
44 
45 
46 
47 
48 
49 



CTC TEST PROGRAM 

THIS PROGRAM USES THE CTC IN CONTINUOUS 
TIMER MODE THE CTC SUPPLIES A BIT RATE 
CLOCK TO THE SIO FROM THE SYSTEM CLOCK 
THE SYSTEM CLOCK IS 3.6864 MHZ, WHICH IS 
DIVIDED BY 16 BY THE PRESCALER, AND DIVIDED 
BY A TIME CONSTANT VALUE OF 3 TO 
PROVIDE A 16X, 4800 BAUD CLOCK 

TO THE SIO. OTHER BAUD RATFS CAN BE OBTAINED 
BY PROGRAMMING DIFFERENT TIME CONSTANT 
VALUES INTO THE CTC. 



PROGRAM EQUATES 



CTCO 
CTC1 
CTC2 
CTC3 
TIME 



CCW. 



EQU 
EQU 
EGU 
EQU 
EQU 



12 

CTCO+1 

CTCO+2 

CTCO+3 

3 



CTC EQUATES 

EQU 1 

INTEN: EQU 
CTRMODE: 

P256- EQU 

RISEDG. EQU 

PSTRT. EQU 

TCLOAD: EQU 

RESET: EQU 



80H 

EQU 

20H 

10H 

8 

4 

2 



i CTC PORT 
, CTC 1 PORT 
, CTC P PORT 
; CTC 3 PORT 
; TIME CONSTANT VALUE-. 



40H 



*E 



BEGIN: 



*** MAIN PROGRAM *** 

ORG 

LD A, TCLOAD+RESET+CCW 

OUT <CTC2>,A , SET CTC MODE 

LD A, TIME 

OUT (CTC2),A , SET TIME CONSTANT 

MAIN PROGRAM GOES HERE 



*E 



JR 
END 



i LOOP FOREVER 



COUNTER MODE A typical computer system often uses a 
time-of-day clock. In the United States, the 
60 Hz power line provides an accurate time 
base for synchronous motor clocks, A computer 
system can take advantage of the 60 Hz 
accuracy by incorporating a circuit that 
feeds 60 Hz square waves into a CTC channel. 
With a time constant value of 60, the CTC 
generates an interrupt once every second, 
which can be used to update a time-of-day 
clock. The CTC is set to Counter mode and 
with a time constant value of 60, as shown in 
Figure 5. 

The interrupt service routine does nothing 
more than update the time-of-day clock. A 
more sophisticated operating system kernel 
would use the CTC to check the task queue 
status. In synchronous data communications, 
it is often necessary to ensure that a flag 
or sync character separates two adjacent 
message packets. Since some serial control ler 
devices have no way to determine the status 
of sync characters sent, the user must use 



time delays to separate messages with the 
appropriate number of sync characters. 
Typical ly, software or timer delays are used 
to provide the time necessary to allow the 
characters to shift out of the serial device. 
The disadvantage of using this method Is that 
variable baud rates shift characters at 
variable times so a worst-case time must be 
allowed if the baud rate is not known. If the 
bit rate clock is supplied by the modem, as 
is normally the case, this problem becomes 
even more acute. 



A solution to this problem is to use a 
counter to count the number of bits shifted 
out of the serial device. With the CTC tied 
to the transmit clock line of the serial 
device, the CTC can be programmed to delay a 
certain number of bits before the CPU sends 
another message. This solves a I I of the pro- 
blems mentioned and simplifies the message- 
handling software. Figure 6 shows the program 
needed to achieve the counting function. Note 
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that the interrupt service routine disables 
the CTC, because the CTC is used only once 
with each message. Otherwise, the CTC would 
generate an interrupt each time the counter 



reached terminal count. 

Figure 1 shows the hardware implementation of 
the character delay counter using the CTC. 



C start) 




w 


INITIALIZE CPU 




v 


INITIALIZE CTC 




v 




SETUP DISPLAY 




i 


i 




ENABLE INTERRUPTS 










\ 


f* 




LOOP 











( ENTER ) 



SAVE REGISTERS 



SWITCH 
DISPLAY STATE 



C EXIT ) 



LQC 



a) Main Program b) Interrupt Service Routine 

Figure 5« Software for CTC Counter Mode 



TEST CTC1 
OBJ CODE M STMT SOURCE STATEMENT 



CTC TEST PROGRAM 



3 


, 


THIS PR 


DGRAM CO 


JNTS 


4 
5 
6 
7 
8 


' 


CHANGES 


THE LED 


STA 


' 


PROGRAM 


EQUATES 




CTCO: 


EQU 


12 




9 


CTC1- 


EQU 


CTCO+1 




10 


CTC2- 


EQU 


CTCO+2 




11 


CTC3: 


EQU 


CTCO+3 




12 


LITE: 


EQU 


OEOH 




13 


RAM 


EQU 


2000H 




14 


RAMSIZ 


EQU 


1000H 




15 


COUNT 


EQU 


60 




16 










17 










18 


, 


CTC EQUATES 




19 










20 


ccw- 


EQU 


1 




21 




INTEN 


EQU 


80H 


22 




CTRMODE 




EQU 


23 




P256. 


EQU 


20H 


24 




RISEDG 


EQU 


10H 


25 




PSTRT 


EQU 


8 


26 




TCLOAD- 


EQU 


4 


27 




RESET 


EQU 


2 



CTC 





PORT 


CTC 


1 


PORT 


CTC 


p 


PORT 


CTC 


3 


PORT 


LIGHT 


PORT 


RAM 


START ADDR 



i COUNTER TIME CONSTANT 



40M 
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LOC 



TEST. CTC1 
OBJ CODE M STMT SOURCE STATEMENT 



OOOO 
0000 



0010 



C31800 



0010 


3800 


0012 


3B00 


0014 


3800 


0016 


3800 


0018 


314020 


001B 


ED5E 


001D 


3E00 


001F 


ED47 


0021 


CD2700 


0024 


FB 



0027 


3EC7 


0029 


D30D 


002B 


3E3C 


002D 


D30D 


002F 


3E10 


0031 


D30C 


0033 


AF 


0034 


324020 


0037 


C9 



0038 


FB 


0039 


ED4D 


003B 


CD4800 


003E 


3A4020 


0041 


2F 


0042 


324020 


0045 


D3E0 


0047 


C9 



0048 


E3 


0049 


D5 


004A 


C5 


004B 


F5 


004C 


CD5600 


004F 


Fl 


0050 


CI 


0051 


Dl 


0052 


El 


0053 


FB 


0054 


ED4D 



0056 



E9 



28 


*E 






29 








30 


, ; 


*** MAIN PROGRAM *** 


31 








32 




ORG 





33 




JP 


BEGIN 


34 








35 




ORG 


*. AND. OFFFOH. OR. 10H 


36 


INTVEC: 






37 




DEFW 


ICTCO 


38 




DEFW 


ICTC1 


39 




DEFW 


ICTC2 


40 




DEFW 


ICTC3 


41 








42 


BEGIN: 






43 




LD 


SP,STAK ; INIT SP 


44 




IM 


2 ; VECTOR INTERRUPT MODE 


45 




LD 


A, INTVEC/256 ; UPPER VECTOR BYTE 


46 




LD 


I, A 


47 




CALL 


INIT ; INIT DEVICES 


48 




EI 


i ALLOW INTERRUPTS 


49 








30 




JR 


* l LOOP FOREVER 


51 








52 


INIT: 






53 




LD 


A, INTEN+CTRMODE+TCLOAD+RESET^CCW 


54 




OUT 


(CTC1), A ; SET CTC MODE 


55 




LD 


A, COUNT 


56 




OUT 


<CTC1>,A iGET TIME CONSTANT 


57 




LD 


A, INTVEC. AND 1HUOO0B 


58 




OUT 


<CTCO),A ;QE-T VECTOR VALUE 


59 




XOR 


A 


60 




LD 


<DISP),A i CLEAR DISPLAY BY »E 


61 




RET 




62 


*E 






63 








64 


, 


INTERRUPT SERVICE ROUTINE 


65 








66 


ICTCO. 






67 


ICTC2: 






68 


ICTC3: 






69 




EI 


i DUMMY ROUTINES 


70 




RETI 




71 








72 


ICTC1: 






73 




CALL 


SAVE iSAVE REGISTERS 


74 




LD 


A, (DISP) i BLINK LITES 


75 




CPL 




76 




LD 


(DISP), A 


77 




OUT 


(LITE), A 


78 




RET 




79 








80 


, 


SAVE 


REGISTER ROUTINE 


81 








82 


SAVE: 






83 




EX 


(SP), HL 


84 




PUSH 


DE 


85 




PUSH 


BC 


86 




PUSH 


AF 


87 




CALL 


GO 


88 




POP 


AF 


89 




POP 


BC 


90 




POP 


DE 


91 




POP 


HL 


92 




EI 




93 




RETI 




94 








95 


00. 






96 




JP 


(HL) 


97 


*E 






98 
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TEST CTC1 
LOC OBJ CODE M STMT SOURCE STATEMENT 



2000 
2000 



99 


, , 


DATA 


AREA 




100 










101 




ORG 


RAM 




102 




DEFS 


64 


i STACK AREA 


103 


STAK 


EQU 


* 




104 


DISP: 


DEFS 


1 


; LITE DISPLAY BYTE 


105 










106 




END 







Q START J 


\ 


i 


[ INITIALIZE CPU | 


l 


r 


| INITIALIZE CTC | 


y 


f 


1 SETUP 1 
1 SOFTWARE FLAG I 


i 


' 


ENABLE INTERRUPTS 1 


1 




i 


READ FLAG BYTE 



BIT XN 



\0 SET y/ 

Y 


^ 


1 RESET BIT 




i 


i 




START CTC 











C ENTER ) 



SAVE CPU STATUS 



SOFTWARE 
RESET CTC 



I SET FLAG BYTE I 



RESTORE CPU STATUS 



(return) 



a) Main Program 



b) Interrupt Service Routine 



Figure 6* Software for CTC Single-Cycle Use 
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LOC 



TEST. CTC3 
OBJ CODE M STMT SOURCE STATEMENT 



0000 
0000 



0010 



C31800 



0010 


4100 


0012 


4100 


0014 


4100 


0016 


4400 



0018 


318120 


001B 


3E00 


001D 


ED47 


001F 


ED5E 


00? 1 


3E10 


0023 


D30C 


0025 


3E01 


0027 


320020 


002A 


FB 


002B 


3A0020 


002E 


CB47 


0C30 


28F9 


0032 


CB87 


0034 


320020 


0037 


3ED5 


0039 


D30F 


003B 


3E14 


003 D 


D30F 


003F 


18EA 



1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 

21 

22 
*■»** 

24 
25 
26 
27 
28 
29 
30 
31 
32 
33 
34 
35 
36 
37 
38 
39 
40 
41 
42 
43 
44 
45 
46 
47 
48 
49 
50 
51 
52 
53 
54 
55 
56 
57 
58 
59 
60 
61 
62 
63 
64 
65 
66 
67 
68 
69 
70 
71 
72 



CTC TEST PROGRAM 

THIS PROGRAM INITIALIZES CTC INTERRUPT VECTOR, 
THEN STARTS CTC 3, THEN WAITS FOR CTC 3 TO 
TERMINATE. AFTER TERMINATING, THE CTC INTERRUPT 
THE CPU AND ENTERS A SERVICE ROUTINE THAT SETS 
A PROGRAM FLAG TO INDICATE ZERO COUNT, AND 
RESETS CTC 3. 



RAM: 

RAM3IZ: 

CTCO: 

CTC1: 

CTC2: 

CTC3: 

COUNT: 



CCW: 



EQUATES 

EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 



*E 



INTVEC: 
CTCVEC: 



BEGIN: 



LOOP: 



*E 



ICTCO: 
ICTC1: 



2000H 

1000H 

12 

CTCO+l 

CTC0+2 

CTCO+3 

20 



CTC PARAMETERS 



EQU 

T klTCkl. 



1 



CTRMODE: 
P256: EQU 
RISEDG: EQU 
PSTRT: EQU 
TCLOAD: EQU 
RESET: EQU 



EQU 
20H 
10H 
8 

4 
2 



j RAM START ADDRESS 

iRAM SIZE 

;CTC PORT 

;CTC 1 PORT 

iCTC 2 PORT 

iCTC 3 PORT 

i COUNT 20 PULSES 



;CTRL BYTE 

; I NT ERR. ENABLE 

40H i COUNTER MODE 

;PRESCALE BY 256 

; START ON RISING EDGE 

i PULSE STARTS TIMING 

iTIME CONST. FOLLOWS 

; SOFTWARE RESET 



ORG 
JP 



ORG 



DEFW 
DEFW 
DEFW 
DEFW 





BEGIN ;G0 MAIN PROGRAM 

*. AND. OFFFOH. OR. 10H 



ICTCO 
ICTC1 
ICTC2 
ICTC3 



MAIN PROGRAM 



LD 


SP,STAK 




i INIT SP 


LD 


A, INTVEC/256 


i INIT VECTOR REG. 


LD 


I, A 






IM 


2 




j VECTORED INTERRUPT 


LD 


A, CTCVEC. 


AND. 


11111000B 


OUT 


(CTCO), A 




i SETUP CTC VECTOR 


LD 


A, 1 




iSET FLAG BYTE 


LD 


(FLAG), A 






EI 








LD 


A, (FLAG) 




iRFAD FLAG BYTE 


BIT 


0, A 






JR 


Z,LOOP 




; BRANCH IF NOT SET 


RES 


0, A 




i CLEAR FLAG BYTE 


LD 


(FLAG), A 






LD 


A, INTEN+CTRMODE+RISEDG+TCLQAD+1 


OUT 


(CTC3), A 




iLOAD CTC 3 


LD 


A, COUNT 






OUT 


(CTC3), A 






JR 


LOOP 







INTERRUPT SERVICE ROUTINES FOR CTC 
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TEST. CTC3 




LOC 


OBJ CODE M STMT 


SOURCE 


STATEMENT 








73 


ICTC2: 








0041 


FB 


74 




EI 






0042 


ED4D 


75 
76 
77 


ICTC3: 


RETI 






0044 


08 


78 




EX 




AF, AF' 


0045 


3E03 


79 




LD 




A, 0000001 IB 


0047 


D30F 


80 




OUT 




(CTC3), A 


0049 


3A0020 


81 




LD 




A, (FLAG) 


004C 


CBC7 


82 




SET 




0, A 


004E 


320020 


83 




LD 




(FLAG), A 


0051 


08 


84 




EX 




AF, AF' 


0052 


FB 


85 




EI 






0053 


ED4D 


86 
87 
88 


*E 


RETI 










89 


; ; 


DATA 


AREA 






90 










2000 




91 




ORG 




RAM 


2000 




92 


FLAB: 


DEFS 




1 


2001 




93 




DEFS 




128 






94 


STW: 


EQU 




* 






95 














96 




END 







i DUMMY INTERRUPT ROUTI 



i RESET CTC 3 
iSET PROGRAM FLAG 



i PROGRAM FLAG BYTE 



CONCLUSION The versatility of the Z80 CTC makes it use- 

ful In a myriad of applications. System 
efficiency and throughput can be Improved 
through prudent use of the CTC with the Z8 
CPU. Coupled with the powerful, vectored 



Interrupt capabilities of the Z80 CPU, the 
CTC can be used to supply counter/timer func- 
tions to the CPU. This reduces software over- 
head on the CPU and significantly Increases 
system throughput. 
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Interfacing 16-Pin Dynamic RAMS 
to the Z80A Microprocessor 
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INTERFACING 16-PIN DYNAMIC RAMS 
TO THE Z8 0A MICROPROCESSOR 



This application note will present the major design 
considerations and a design example for interfacing the 
16-pin dynamic RAM devices, both 4K and 16K, to the Z80 
and Z80A microprocessors. These devices will be 
emphasized because they are fast becoming the favorite 
memory component for data storage in microprocessor 
based systems. The 16K RAM (Zilog 6116), in 
particular, with design improvements over the 4K 
devices, will substantially reduce memory cost by 
quadrupling memory density in a package that is pin 
compatible with the 4K RAM. 

This application note assumes a basic understanding of 
the Z80A CPU and dynamic RAM elements. The reader is 
referred to selected specification sheets on the various 
4K and 16K dynamic RAMS and to the following Zilog 
literature: 



Z80A CPU Technical Manual, and 

Z6116 16K Dynamic RAM Product Specification 
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INTRODUCTION 



16-pin dynamic RAMs are increasingly being used as the 
memory component for data storage in microprocessor- 
based systems. Their main features are low cost per bit 
and high bit density. These features, coupled with a 
low stand-by power mode, TTL-compatible inputs and 
outputs, and simple upgrade from 4K to 16K systems, have 
made these devices an attractive alternate to 18- or 
22-pin dynamic RAMs. 

Now, however, the system designer has to be concerned 
with the interface requirements of 16-pin dynamic RAMs. 
The characteristics of this memory element requires that 
refreshing of the memory be performed at periodic 
intervals in order to retain the stored data. This, 
coupled with the requirement for multiplexing address 
lines, has been the main drawback to their use. A 
typical interface generally required 12 to 20 standard 
TTL devices and included timing generators, decode 
logic, multiplexer circuitry, refresh logic, and 
buffers. 

The Zilog Z80A microprocessor has been designed to 
simplify this interface with built-in refresh logic. 
This allows totally transparent RAM refresh without the 
need for a refresh counter or its associated 
multiplexer. During each me mory opcode fetch cycle, a 
dedicated line from the CPU (RFSH) is used to indicate 
that a refresh read of all dynamic memories should be 
performed. With RFSH in the true state (LOW), the lower 
seven bits of the address bus identify one ROW address 
to be refreshed. Before the next opcode fetch, this 
address will have been incremented to point to the next 
ROW address. Since it is only necessary to refresh the 
'ROWS 1 , a total of 64 refresh cycles will refresh an 
entire 4K RAM, or 128 refresh cycles for a 16K RAM. 
Z80A-CPU refreshing is automatically performed during a 
portion of the instruction fetch cycle which is used for 
internal processing. Thus, the effect of refreshing the 
RAM is totally transparent to program execution, 
preventing the necessity of stealing cycles or stopping 
the CPU as would otherwise be required. 
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16 PIN DYNAMIC RAM ADDRESSING 



Each cell of a dynamic RAM array is arranged in a 
matrix. Selection of a unique bit location within this 
matrix in a 4K RAM element will require 12 address lines 
while the 16K device requires 14. For the 16-pin RAM 
device to accommodate these lines, it will be required 
to divide them into two groups; Row addresses and Column 
addresses (six each for the 4K RAM and seven each for 
the 16K RAM) . Each group is applied to the RAM on the 
same input lines (Figure 1) through an external 
multiplexer and latched into the chip by applying two 
clock strobes i n suc cession. The first clock, the Row 
Address Strobe (RAS) , latches the Row address bits into 
the RAM (A0-A5 for the 4K f A0-A6 for the 16K) . The 
second clock, the Column Address Strobe (CAS) , latches 
the Column address bits, (A6-A11 for the 4K, A7-A13 for 
the 16K) into the RAM. 

Each cell, the ref ore, is uniquely addressed by row and 
column. When RAS goes active, all of the cells in the 
selected row respond (there are 64 rows in the 4K RAM 
matrix and 128 rows in the 16K RAM matrix) and are gated 
to sense amplifiers where the logic level o f e ach cell 
is discriminated, latched, and rewritten. CAS activates 
a column in the matrix (there are 64 columns in the 4K 
RAM matrix and 128 columns in the 16K RAM matrix) which 
uniquely identifies the cell in the row output and 
yields the required bit to the output buffer. 

During refresh, the interface logic will enable the Row 
Address lines from the multiplexer. The CPU, with a 
true condition on the Refresh line (RFSH) , will then 
present the address (A0-A7) of the Ro w to b e refreshed, 
and activate the memory request line (MREQ) to initiate 
a memory cycle. 
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V BB 
D IN 

WRITE 3 C 
RAS 4 C 



'DD 




V SS 
CAS 

^OUT 
CS 

A 



'CC 



PIN NAMES 

AQtA 6 

Ca3 

gOUT 
RA3 



WRITE 

V BB 

v C c 

Vdd 



ADDRESS INPUTS 

COLUMN ADDRESS STROBE 

DATA IN 

DATA OUT 

ROW ADDRESS STROBE 

READ/WRITE INPUT 

POWER (-5V) 

POWER ( + 5V) 

POWER ( + 12V) 

GROUND 



V BB 
D IN 
WRITE 
RAS 



'DD 



4KRAM 



c 


• 


116 


c 




:i5 


r 


c 




D14 


c 




] 13 


c 




D 12 


c 




D 11 




L J 


D 10 

19 




16K RAM 



V SS 
CAS 



'OUT 



'CC 



FIGURE 1. The pin assignments for 4K and 16K RAMs show 
identical functions for each, except Pin 13, which is 
used as a chip select in 4K RAMs and as the 7th 
multiplexed address line in the 16K RAM. 
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MEMORY REFRESH 



When any row in a 16-pin dynamic RAM is actively cycled, 
all locations within that row are refreshed. To refresh 
the entire RAM, it is only necessary to perform a RAS 
only memory cycle (CAS is not required for a refresh 
sequence) at each of the 64 row addresses for the 4K 
device and 128 row addresses for the 16K device, every 2 
milliseconds or less. 

The Z80 CPU refreshes the memory more frequently than is 
necessary to meet the 2ms row refresh requirement. Under 
worst case conditions, no more than 19T states will 
separate opcode fetch cycles (the EX (SP) ,HL instruction 
is representative of the longest time between opcode 
fetches) . Assuming this worst case period between 
opcode fetches and, therefore, refresh cycles, the 
following times for total refresh for both 4K and 16K 
RAMS at 2.5 MHZ and 4 MHZ are shown below: 



REFRESH TIME 


MEMORY 
SIZE 


Z80-CPU 
2.5 MHZ 


Z80A-CPU 
4.0 MHZ 


NO. OF REQUIRED 
REFRESH CYCLES/2 mS 


4K 
16K 


487 us (max) 
974 us (max) 


304 us (max) 
608 us (max) 


64 
128 



TABLE 1. WORST CASE MEMORY REFRESH CYCLES ASSUMING NO 
WAIT STATES 

From the above table, it can be seen that the worst case 
refresh time for 16K RAMS consumes approximately 1/2 of 
the available 2ms time interval while the 4K RAM 
consumes only about 1/4 of the allotted time. This 
provides for optional use of the refresh cycle for other 
CPU transparent bus activity, such as DMA and CRT 
refresh. 
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ACCESS TIME 



Most dynamic RAMS have access times in the range of 
150ns to 300ns. This access beg ins with the leading 
edge of the row add ress strobe (RAS) . The column 
address strobe (CAS) comp let es this access c ycle . The 
time between the f all of RAS and the fall of CAS is 
identified as the RAS to CAS delay time (tRCD) , and can 
be related to the previous access times as follows: 

tRACmax = tRCDmax + tCACmax 



WHERE tRACmax = Access time from RAS 



tRCDmax = max RAS to CAS delay time 

tCACmax = Access time from CAS 

As long as tRCD is less than max value ( but greater than 
tRCDmin) , the worst case access is from RAS (see Figure 
1) . If CAS is applied at a point i n ti me beyond the 
tRCDmax limit, the access time from RAS will be 
lengthened by the amount that tRCD exceeds the tRCDmax 
limit and the access time from CAS (tCAC) will be the 
critical parameter. Note, however, that reducing tRCD 
to something less than tRCDmax will have no effect at 
reducing tRACmax. 

The significance of the min/max value on tRCD is that 
"CAS can be brought low any time within this window and 
not affect access time. This is a grea t improvement 
from early 4K designs that req uire d CAS to be brought 
low at a set minimum time from RAS low in order to avoid 
increasing access time. This made no allowance for the 
time required to switch the MUX from ROW to COLUMN 
addresses, requiring that the worst case multiplexing 
time delay be added to the specified access time. 

This window, for the app lication of the external CAS, is 
the resu lt o f gating CAS internal to the chip. The 
internal CAS is inhibited u ntil the occurren ce o f a 
delayed signal derived from RAS. Therefore, CAS can be 
activated as soon as the requirement for the row address 
hold time (tRAH) has been satisfied and the address 
inputs have been changed from row to column. Note that 
the column address set-up time (tASC) can be assumed to 
be zero for all dynamic RAMs (See Figure 2) . 
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Figure 2 Dynamic ram access time parameters 
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Z80A/Z80 - CPU TIMING CONSIDERATIONS 



The Z80A/Z80 CPU is designed to allow efficient and 
effective interface with dynamic RAM memories. Figures 
3 through 8 identify the timing for CPU data, address 
signals, and control signals associated with memory 
interface for the Z80A and Z80. The opcode fetch, with 
its associated refresh cycle, will represent the worst 
case memory access, requiring data to be returned to the 
CPU in the first two T states. Memory read and write 
cycles have relaxed timing requirements as indicated in 
Figures 5 through 8. This will require memories with 
access times of 250ns or less for the Z80A and 400ns or 
less for the Z80. These numbers, however, do not take 
into consideration the propagation delays through any 
buffer logic added. 

Notice that addresses are stable well before MREQ goes 
active, giving sufficient time for address decode logic 
to settle. The mai n c oncern, therefore, is propagation 
delay from MREQ to RAS. This should be kept to a 
minimum since it will directly affect access time. 

From Figure 7, it can be seen that write (WR) goes 
active on the trailing edge of T2. The CPU, th erefore, 
usually performs a read-mod if y-wr ite cycle (CAS before 
WR) . To utilize the early write cycle (WR active before 
CAS) and allow 16K systems to tie their inputs and 
outputs together, the read line (RD) from the CPU can be 
inverted and used instead of WR. This re qui res, 
however, that write data be valid before CA& . 

From Fig ure 4, it can be seen that the minimum high time 
for MREQ between opcode fetch and refresh cycl es is 

105ns for the Z80A. For systems that use MREQ to 

generate RAS, this is not sufficient to satisfy RAS 
precharge time requirements of the slower RAMs. 
However, as will be shown in the design example, 
relatively simple logic can be used to extend kAS high 
time between these cycles. 
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Figure 3 Z80-CPU op code fetch cycle timing at 2.5 MHz clock 
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Figure 4 Z80A-CPU op code fetch cycle timing at 4 MHz clock 
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Figure 5 Z80-CPU read cycle timing at 2.5 MHz clock 
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Figure 6 Z80A-CPU read cycle timing at 4 MHz clock 
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Figure 7 Z80-CPU write cycle timing at 2.5 MHz clock 
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MEMORY CYCLE SELECTION 



Selection of a n op erati ng mo de is cont rolled by a 
combination of CAS and WRITE while RAS is active. The 
available modes in most 4K and 16K RAMS are a read 
cycle, a write cycle, a read-write cycle, and a 
read-modify-write cycle. For some of the newer 4K 
devices and the 16K device, another type of cycle known 
as page mode allows for faster access time by keeping 
the same row address and strobing successive column 
addresses onto the chip. 

The read-modify-write cycle can be accomplished in less 
time than a read cycle followed by a write cycle because 
the addresses do not change in between. It is, 
therefore, possible to generate the write strobe as soon 
as the data modification is complete. In other words, 
data is read from a cell, modified, and then rewritten 
in its modified form into the same cell. In contrast, a 
read-write cycle does not require data to be valid at 
the output before the write operation is started. 

In a wr ite cycle, if the WRITE input is brought low 
before CAS (early write) , the data is strobed in by CAS. 
In a delayed write cycle, the W RITE l ine goes low after 
CAS and data is strobed in with WRITE. 
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DYNAMIC RAM MEMORY ORGANIZATION 



Careful attention must be given to dynamic RAM memory 
array layout. Page decoding, power line routing and 
filtering, noise suppression and generation, buffer 
drive requirements, and system upgrading are all 
important considerations during the design phase. 

If a memory array consisting of 4K devices exceeds 4K 
bytes (one page) , it will be necessary to configure 
multiple rows. Each row, or page, is selected by 
decoding address lines A12-A15. If the system is 
intended to be upgraded with 16K devices, the chip 
select line (CS) shou ld not be used for device 
selection. I nst ead, RAS should be gated to the selected 

4K bank with CAS being a ppl ied to all devices. (Chips 

that receive CAS but no RAS will be unselected.) The CS 
line should be distributed to all devices and tied to 
ground. It can then be used as the seventh address line 
when upgrading to 16K RAMS. 

The CAS line is used to control the output buffer in a 
configuration where the outputs are or-tied. If true 
data is still available from a pr evious cycle (assuming 
latched output 4K RAMS) , then CAS deselects these 
devices if they are not being acc esse d during the 
cur rent cycle. Note also that if RAS is inactive and 
CAS active, the only function that is performed is to 
change any true outputs to the high impedance state. 
Figure 9 shows the logic for one data bit in an 8K-byte 
system utilizing two banks of 4K RAM devices. 

The absence of an output latch on most 16K RAMS can 
allow for simplification in system design. Unlike the 
latched 4K devices which need an extra cycle to clear 
the latch, the 16K non-latched dev ice maintains data 
valid only during the time the CAS clock is active. 
Each memory cycle, therefore, can be maintained as an 
independent cycle, allowing the data input and output 
pin to be directly connected. This is assumin g , 
however, that the write line goes true before CAS (early 
write mode) . 
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All inputs on mo st dy nam ic RAMS ar e TTL compatible (on 
some 4K devices RAS", CAS*, and the WRITE line require a 
2.7 volt minimum logic 1 level which will require a 
pull-up resistor on the TTL driver). These TTL inputs, 
however , do not source current; but instead, present 
purely capacitive loads. This capacitance will vary 
between 5pf and lOpf on most 4K and 16K devices. With a 
large number of RAMS in a memory array, capacitive 
loading becomes a consideration. A 16K byte memory 
array made up of 4K devices will present from 150pf to 
250pf of input capacitance to the input buffers. Most 
TTL outputs are not specified above 50pf. Therefore, a 
TTL driver must be used that can provide enough charging 
and discharging current to achieve the required voltage 
transition within the allotted time. A fairly accurate 
calculation can be made for determing the required drive 
current by using the standard relationship between the 
charging current i, the capacitance C, the voltage 
transition V, and the allotted time T: 

AV 
i = C — 

AT 

For example, if the worst case capacitance on an address 
line is 250pf and it is required to change this address 
line within a 60ns period from zero volts to 3 volts, 
the driving current is: 

(3) 

i = 250 x 10~ 12 = 12mA 

60 x 10" 9 

The power consumption of dynamic RAMS, which generally 
var ies f rom 350mw to 1 watt, depends on the state of the 
RAS and CAS clocks. The device draws minimum current 
when these clocks are inactive (standby mode) . At each 
transition of the clocks, the device will draw current. 
This current corresponds to the precharging of these 
lines which represent large capacitance loads. During 
standby, the power consumption is usually less than 
20mw. Also, because of this very low power dissipation 
when the clo cks are turned off, the technique of 
decoding RAS to selected chips results in a sizable 
decrease in power consu mpt ion (approximately 60% o f a ll 
active power is due to RAS and only 40% is due to CAS) . 
Because the memory is dynamic, the power dissipation is 
a function of the rate of memory access and, therefore, 
operating frequency. 
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The resu lting current spike, which occurs when the RAS 
and CAS clocks go through their negative transitions , is 
coupled onto the power supply busses causing noise 
throughout the system. To compensate for this noise , 
high-frequency ceramic bypass capacitors should be 
placed within the memory array. A good practice is to 
supply a .luf capacitor every other device between +12V 
and ground. Alternating between these capacitors , a 
Decoupling on the +5V line to prevent noise from 
affecting TTL logic should consist of a .Oluf capacitor 
every 4 or 5 devices. For low frequency decoupling, a 
lOuf tantalum capacitor between +12 and ground should be 
supplied every 16 devices with a lOuf tantalum between 
-5V and ground every 32 devices. 

The use of a multi-layer board with internal power and 
ground planes would be beneficial in a dynamic RAM 
system. However, proper routing of power lines on a 
two-sided card should provide satisfactory results. It 
has been found that bussing the +12 volt and ground 
lines both horizontally and vertically, at every device 
will reduce noise and greatly improve RAM performance. 
The -5 and +5 volt lines need not be bussed in this 
fashion since they are less heavily loaded and are less 
likely to see current spikes. 

Keeping the layout as small as possible and locating the 
address and data bus buffers as close to the array as 
possible will also reduce potential ringing and 
reflections . 

Figure 10 represents a typical expandable RAM interface 
for a total memory capability of either 16K using 4K 
devices or 64K using 16K devices. The multiplexing of 
address lines is done by "wire-oring" 8T97 drivers and 
controlling the tri-state input for row to column 
switching. Since the minimum voltage on any RAM input 
is -1 volt, a small series resistor (about 30ohms) is 
inserted on each RAM address line to surpass any 
undershoot that might occur. When using 4K RAMs, the 
lower section of the 74S139 decoder selects the desired 
16K quadrant by decoding address lines A14 and A15. The 
upper section of the decoder selects the desired 4K bank 
in this quandrant by decoding address lines A12 and A13. 
When using 16K RAMs, the lower section of the decoder is 
not used and the upper section decodes the desired 16K 
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Figure 10 Z80A-16K/64K dynamic ram interface 



quadrant with address lines A14 and A15. The latch on 
the upper addr ess line is u sed to prevent potential 
spikes on the RAS lines as MREQ and the address lines 
change at the end of the cycle. 

The use of 8T97 drivers, with an external pull-up 
resistor, will insure proper logic level and capacitance 
drive capability. When using 4K devices, memory address 
line 6 (MA6) is not needed and tied to ground (this is 
the chip select line on 4K RAMs) . When using 16K RAMs, 
this line is the 7th address line (A6 for row and A13 
for column) . 
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SLOW MEMORY INTERFACE 



When working with memory devices with long access times 
(2708 EPROMS with a 450ns max access time, for example) , 
it will be necessary to add wait states to Z80A timing. 
Figure 11 shows how a JK flip-flop can be configured for 
adding one wait state (250ns with a 4MHz clock) to each 
memory cycle. When using dynamic memories that have 
access times between 250 and 350ns , it is only necessary 
to add wait states for Op Code fetch cycles, since this 
cycle is the critical one in terms of memory access 
requirements. In this case, th e lo gic in Figure 11 can 
be controlled by Ml instead of MREQ to accommodate these 
memories. 
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DESIGN EXAMPLE 



A typical design is presented to demonstrate a technique 
for dynamic RAM interface to the Z80A operating at 4MHz. 
Of the several approaches that could have been used for 
generating the timing signals needed for this interface , 
the tradeoffs for considering this approach consisted of 
the following: 

1. Monostable-multivibrators could have been used to 
generate the time delays for the MUX switching and 
CAS signals, but one-shots are hard to adjust and 
are less reliable than other approaches. 

2. The inherent delay in low power TTL gates could be 
used for this timing, but predictable timing 
intervals are hard to achieve at 4MHz. 

3. A tapped delay line produces very accurate timing 
signals but is less attractive from a cost 
standpoint. 

A synchronous technique has been chosen for this design 
because it generates accurate signals with a minimum of 
logic complexity and produces predictable results from 
system to system. The approach is to generate the CPU 
4MHz clock from an 8MHz source. This 20 clock is then 
divided by two and used with th e resulting c loc k to 
generate the MUX switch and CAS sign als after RAS has 
been generated from the fall of MREQ. Figure 12 is a 
schematic diagram of this interface. Figure 13 
indicates the timing relationship involved. 



The ROW Address Strobe (RAS) is generated at the fall of 
MREQ. On the next rising edge of the clock, ! A' 
flip-flop is clocked to generate the signal used to 
switch the multiplexer from ROW addresses to Column 
addresses. The followi ng f alling edge of the 20 clock 
is used to generate the CAS signal (B flip-flop) . 
Flip-flop C is used to insure sufficient RAS prec harge 
time, which must be taken into account since MREQ has a 
minimum high time o f 10 0ns between Op Code fetch and 
refr esh cycles and M REQ , therefore, cannot be used to 
set RAS high. With CAS true, the trailing edge of RAS 
is clocked high with the clock. This will extend the 
RAS high time to approximately 150ns. 
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Figure 12 Z80A dynamic ram interface 
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Figure 13 Z80A dynamic ram interface timing 



This basic logic structure is configured into a 
microcomputer system and is seen in Figure 14. For 
simplicity, only the logic pertaining to the RAM 
interface is shown. Additional logic consisted of 
monitor software and a serial I/O interface to a CRT 
terminal . 

Calculated timing parameters matched measured data quite 
accurately. Figures 15 through 20 indicate recordings 
taken during the Op Code fetch and refresh cycles at 
room temperature and at a Vcc of +5.0 volts. 

From Figure 19 , it c an be seen that the interval between 
the leading edge of RAS and the leading edge of the 
switch MUX signals is approximately 50ns. The 
calculated interval is 35ns minimum and is consistent 
with the ROW address hold time tRAH (see Z6116 Product 
Specification) of all RAMs that are access time 
compatible with the Z80A. 

At the leading edge of the switch MUX signal, the RAM 
addresses are switched from ROW to Column addresses. 
Assuming the column address set up time (tASC) to be 
zero (consistent with most dynamic RAMs) , the interval 
for address switching is approximately 70ns as confirmed 
from calculated and measured data (see Figures 13 and 
19). Scope triggering records both Row and Column 
addresses which appear to be superimposed on a typical 
RAM address line as seen in Figure 17. 



Since the RAS to CAS interval exceeds the tRCD max value 
of most access-compatible RAMs, th e R AM access tim e i s 
measured from the leading edge of CAS. RAMS with CAS 
access times of 150ns or less should be compatible with 
thi s in ter face approach. If it is desired to keep the 
RAS to CAS interval within or closer to the tRCD max 
limit, a 40 clock could be applied to the clock input of 
Flip-Flop B (Figure 12) ins tead of the 20 clock. This 
would reduce the RAS to CAS interval to approximately 
65ns. 



2-143 



;> 



> 






^ 



c> 



d- 



E- 






1> 



C- 



xr_r 



>£ 



in 



i> 



t> 



in 



n 






^5>- 




:==g^ 






a < 



xn- 



TTT 




>A 



Figure 13 Z80A 16K ram interface 



2-144 



FIGURE 15 



FIGURE 18 




FIGURE 16 



FIGURE 19 




CK 



RAS 



SM 



CAS 




FIGURE 17 



FIGURE 20 




2-145 



The recordings also show the relation between MREQ and 
RAS high time between Op Cod e fetch and refresh cycles. 
The calculated value for RAS high time was 150ns while 
the measu red value was approximately 170ns. This allows 
adequate RAS precharge time for all access-compatible 
RAMs . 

A composite of all the major control signals, including 
one data line, is seen in Figure 20. This recording, 
done with a logic analyzer, shows the relative relation 
of these signals during the Op Code fetch a nd refresh 
cycles. Notice, that du rin g refresh, only RAS is active 
with the switch MUX and CAS signals disabled. 



CONCLUSIONS 



The high density, reduced standby power, and reduced 
cost per bit of 16-pin dynamic RAMs have made these 
devices suitable for an increasing number of 
applications. Their attractiveness is also enhanced by 
the ease of upgrading from 4K to 16K devices. With this 
increased usage, however, the interface logic between 
the memory array and the microprocessor becomes an 
important consideration. The Z80A has simplified this 
interface. Internal logic operates totally transparent 
to CPU operation, supplying refresh capability without 
the need for a refresh counter and its associated 
multiplexer. This interface can be configured with just 
five st and ar d T TL gates to obtain synchronous generation 
of the RAS, CAS, and the multiplexer switching signal. 
Additional design attention must be given to the RAM 
layout which can have a dramatic effect on system 
performance. Dynamic RAMs tend to be noise generators 
as well as being noise sensitive. However, with proper 
attention to filtering, power line routing, and array 
organization, dynamic RAM memory can provide a cost 
effective solution for high-density storage. 
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Controlling Z80 microcomputer I/O? 
An interrupt-driven program could help 



Although interrupts are not necessarily the fastest 
way to control I/O in a microcomputer system, 
they are often the most practical— especially when 
several asynchronous external events must be serviced 
in preference to ongoing calculations. 

Interrupt processing itself is, of course, a function 
of hardware architecture, but it must be supported 
by special routines in the user's software. To do that 
efficiently requires detailed knowledge of how an 
interrupt functions. 

Say a peripheral generates an interrupt condition 
when a character becomes available on the Z80-SIO 
(serial-I/O) receiver. When the connected peripheral's 
interrupt-enable input line is high and its internal 
interrupt circuitry is enabled, it activates the inter- 
rupt line of the Z80 CPU. 

The processor samples the interrupt line on the last 
T state of the last machine cycle in every instruction. 
If the interrupt line (INT) is active, the interrupt- 
enable flip-flop in the Z80 is set and the data-bus 
request line (BUSRQ) is inactive, the CPU acknowledges 
the interrupt by entering a special Ml cycle called the 
interrupt-acknowledge cycle. An I/O request is then 
made during the last T state of this cycle to the device, 
which is now able to put its vector on the data bus. 
This vector, together with the I register, forms a 16- 
bit pointer in the interrupt service routine's starting- 
address table (ISR-SAT). The Z80 CPU then obtains 
a 2-byte address from the table and jumps to that 
address. 

But before the interrupt can be processed properly, 
the user has to prepare the ground: 

1. An interrupt "page" must be chosen and the I- 
register programmed accordingly. 

2. The device interrupt vector must be pro- 
grammed. 

3. An entry (or several) must be made in the ISR- 
SAT. 

When the interrupt has been acknowledged, the 
machine state can be described as follows: 

■ The user program has been interrupted. 

■ Control has been passed to the proper interrupt 
service routine (to which the table entry for the 



Two other ways 

Besides interrupts, ^C-system I/O can be handled 
by software polling (handshaking) or by direct memo- 
ry access (DMA). 

Software polling is the simplest technique— the 
CPU is left idle until a peripheral is ready to transfer 
data. Even if the inefficient processor use is accep- 
table, transfer rates under 42.3 kbytes/s for the Z80 
or 67.8 kbytes/s for the Z80A are only adequate for 
paper-tape or card readers, and inadequate for tape 
or disk drives. Unless a separate CPU is dedicated to 
I/O, the inefficiency usually makes polling unaccep- 
table. 

Worse yet, while the CPU waits for one peripheral 
to get ready, several others may go begging. So when 
several devices need CPU access according to pre- 
determined priorities, interrupt-controlled I/O is usu- 
ally preferred — especially when asynchronous ex- 
ternal events have to be serviced in preference to some 
ongoing calculations. 

But interrupt servicing also takes time. The Z80 
needs up to 40 T cycles to detect and acknowledge the 
interrupt, in addition to I/O processing. Compared 
with polling, interrupt-driven I/O can be much slower. 
While polling can service a single-density floppy that 
needs data at 31.3 kbytes/s, interrupt control under 
a Z80 CPU would lead to the loss of some data. 

When high speed is critical, DMA takes the prize. 
By synchronizing a peripheral to the central memory 
rather than the CPU, the software overhead of both 
polling and interrupts can be avoided. However, DMA 
excludes the possibility of any data preprocessing 
(field masking, character search), and tends to be 
expensive. Direct memory access is often combined 
with interrupts; for instance, serial communications 
can be started via interrupts, and then carried on at 
high speed under DMA. 



Eric A. Benhamou, Software Group Manager, General 
Systems, Zilog, Inc., 10460 Bubb Rd., Cupertino, CA 
95014. 
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interrupting device is pointing). 

■ All maskable interrupts are disabled, as they 
would be after a Disable Interrupts instruction. 

■ The program then executes the interrupt handler 
routine. Since the Z80 CPU does not preserve the state 
of the system automatically when interrupts occur, 
the interrupt handler must do this job, in one of three 
ways. 

First, registers and flags may be saved on the stack 
with the following sequence of instructions and T 
cycles: 

PUSH AF 11 

PUSH HL 11 

PUSH DE 11 

PUSH BC 11 

PUSH IX 15 

PUSH IY 15 
Total T cycles: 74 

When this method is used, a similar sequence of POP 
instructions restores the stack at the end of the service 
routine: 









ruK 


Y 14 








POP IX 14 


POP BC 10 


POP DE 10 


POP HL 10 


POP AF 10 


Total T cycles: 68 


Second, other RAM locations may be used for the 


same purpose: 


LD (ASAVE).A 13 


LD (HLSAVE).HL 16 


LD (DESAVE),DE 20 


LD (BCSAVE),BC 20 


LD (IXSAVE).IX 20 


LD (lYSAVE)JY 20 


Total T cycles: 109 
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1. A daisy-chain mechanism resolves priority conflicts 
between Z80 peripherals. A device can only interrupt when 
its iei line is high. While being serviced, the interrupting 
device (highlighted) keeps its ieo line low, preventing 
lower-priority devices (gray) from issuing an interrupt. 



The flat register F, however, cannot be saved 
directly in the RAM method—a serious limitation. 
Furthermore, a sequence taking 109 T states could be 
prohibitively long in some applications. 

Third, when interrupt-overhead time and program 
space must both be minimized, the Z80 CPU's alter- 
nate register set may be used to save registers and 
flags. Here, exx exchanges the contents of the BC, DE 
and HL registers with the contents of the BC, DE' 
and HL' registers, respectively, while EX AF, AF 
exchanges the contents of AF and AF'. 

This operation requires only eight T states, 2 bytes 
of code and no additional stack space. However, this 
method is of limited use when multiple interrupts are 
needed since only one interrupt handler may use the 
alternate register set; this excludes the use of nested 
interrupts. The method also assumes that the alter- 
nate register set is not already used by the program 
that is being interrupted. 

Since only those registers whose content is de- 
stroyed by the interrupt service routine need to be 
preserved, a combination of the three methods is 
frequently used. 



More interruptions 

If successive interrupts are to be allowed, the 
interrupt handler must explicitly enable them with 
an Enable Interrupts (El) instruction. This can be done 
anywhere in the program after the first interrupt 
occurs, and before the next one is expected. 

In most cases, however, exactly where in the main 
program an interrupt occurs is not known. Conse- 
quently, it is good practice to enable interrupts in the 
interrupt handler itself. If the interrupt handler 
executes an EI instruction immediately, higher-priori- 
ty devices could interrupt as early as the instruction 
immediately after El, producing nested interrupts. 
Program-timing calculations must take this into ac- 
count. 

When several peripheral devices operate simultane- 
ously in interrupt mode on a Z80 CPU, interrupts from 
any device may have to be acknowledged within a very 
short time to avoid data loss or other I/O malfunc- 
tions. In such cases, interrupts should be reenabled 
as early as possible in the interrupt handler to 
minimize the interval during which real-time events 
will not be recognized. This time will not exceed the 
value T llm , which is defined as follows: 
Turn = Interrupt-acknowledge time 
4- instruction time for EI 
+ instruction time for following instruction 

The Ti lm can be minimized by forcing the instruction 
following El to be a NOP or any other instruction of 
four T states. 

When the programmer allows nested interrupts to 
occur, he must remember that only one service routine 
may use the alternate register set for preserving the 
interrupted program state. If all the interrupt han- 
dlers save registers on the stack, he must verify that 
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2. All interrupt routines start by saving program status, 
which they restore at the end. They terminate with Enable 
Interrupt (ei) and Return from Interrupt ( reti) instructions 
— what happens in between depends largely on the specific 
application. 
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3. Sectors on a floppy disk contain not only data 
(highlighted) but also pre and postambles, as well as 
control information. 
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4. A Z80A CTC chip generates interrupts for a disk 
controller. Its channel counts index or sector pulses (pin 
23), while the cascaded channels 1 and 2 provide a wide 
timing range. 



the stack area is large enough to prevent overflow. 
If nested interrupts are not desirable, the EI instruc- 
tion is usually inserted at the end of the interrupt 
service routine, immediately before the Return from 
Interrupt (RETI) instruction. Any pending interrupt 
will then be delayed until the end of the interrupt 
handler, that is, until RETI has been executed. 

Watch for the daisy chain 

The interrupt handler must terminate with RETI, 
which is decoded by the interrupting device and allows 
the device to leave the interrupt state. In particular, 
it reactivates the lower daisy chain by resetting lines 
IEI (Interrupt Enable In) and IEO (Interrupt Enable 
Out) so that interrupts from lower-priority devices can 
be recognized (Fig. 1). 

Keep in mind that EI and RETI do different things. 
The El instruction does a general interrupt enable on 
the Z80 CPU for maskable interrupts. This does not 
imply, however, that all Z80 peripheral devices are 
allowed to interrupt — only those that have an active 
IEI line. In an interrupt-service routine, therefore, only 
devices higher in the chain than the interrupting 
device may, in turn, interrupt after EI and before 
RETI. 

The RETI instruction is the only way to reestablish 
the interrupt daisy chain, below the interrupting 
device, by software. By resetting the interrupt-under- 
service flip-flop inside the peripheral, RETI affects the 
state of the interrupting device, while EI affects the 
state of the Z80 CPU. 

Fig. 2 shows a generalized interrupt routine that 
summarizes the discussed steps. But the flow chart 
should not be regarded as a rigid model— interrupt 
handlers can differ widely from one application to 
another. 



Making tracks— carefully 

A hard-sectored floppy-disk driver provides many 
opportunities for interrupt-service routines: Sector 
count, head-load-delay time-out and track stepping in 
particular require interrupt techniques to achieve 
acceptable performance levels. 

One problem stems from slight head misalignments, 
which cause the physical location of sector data to vary 
slightly with respect to the sector hole. The impact 
on data readability may be severe because flexible 
diskettes are likely to be read on several drives with 
different alignment characteristics. 

For example, if data are written "early" with respect 
to the sector hole, the read gate may be turned on 
too late to catch the start bit, and synchronization will 
occur on the first ONE bit in the data field. A sector- 
address error or a CRC error are typical results. If 
data are written "late" with respect to the sector hole, 
the last bytes of the previous sector may still be under 
the read head when the read gate is turned on. 

The best point to turn on the read gate is at the 
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; PROGRAM CTC TO REQUIRED MODE OF OPERATION 


LD A,13H 


SET Z80 INTERRUPT REGISTER 


LD I, A 




LD HL,INTO 


LOAD INTRPT ROUT ADDRESS 


LD (CTCOIV),HL ; 


IN INTERRUPT TABLE 


LD A, (CTCOIV.SHL 


.8)/256 


OUT (CTCO) , A ; 


PROGRAM CTC INTRPT VECTOR 


LD A, (COUNT) 




DEC A 


PROGRAM CTC CHAN TO INTRPT 




ON REQUESTED SECTOR - 1 


LD BC,CTRMOD.SHL. 


8+CTCO 


OUT (C) , B ; 


SEND OUT MODE-CTRL BYTE 


OUT (C) , A 


SEND OUT COUNT 


INTO: PUSH AF ; 


SAVE REGISTERS 


PUSH BC 




LD A, 3 ; 


RESET CTC CHANNEL 


OUT (CTCO) , A 




; DELAY 4.5 MS OR 


.9 SECTOR TIME 


LD HL, INTL 


LOAD INTRPT ROUTINE ADDRESS 


LD (CTC2IV) , HL ; 


IN INTERRUPT TABLE 


; PROGRAM CTC1 IN COUNTER MODE, NO INTRPTS 


LD BC, CNTMOD.SHL 


.8+CTC1 


OUT (C) ,B 




LD B,TIME32 ; 


ZERO-COUNT PERIOD = 3 2US 


; PROGRAM CTC2 IN COUNT MODE WITH INTRPTS 


LD BC,CTRMOD.SHL. 


8+CTC2 


OUT (C) ,B 




LD A,DELAY1 ; 


ZERO-COUNT REACHED 


OUT (C),A 


AFTER 4.5 MS 


POP BC 




POP AF ; 


RESTORE REGISTERS 


EI 




RET I 




INT1: PUSH AF 


SAVE REGISTER 


PUSH BC 




PUSH DE 




PUSH HL 




LD A, 3 




OUT (CTC 2) 


RESET CTC CHANNEL 2 


LD HL,INT2 


LOAD INTRPT ROUT ADDRESS 


LD (CTC2IV) ,HL ; 


IN INTERRUPT TABLE 


; PREPARE TO SET 


UP CTC CHANNELS 1 AND 2 


LD C,CTC1 




LD DE , CNTMOD . SHL . 


8+TIME32 


LD HL,CTRMOD.SHL. 


8+DELAY2 


; DETECT REQUESTED SECTOR HOLE 


INT11: IN A, (PIOB) 


INPUT STATUS 


BIT SECTOR, A 


TEST SECTOR + INDEX LINE 


JR NZ, INT11 


LOOP UNTIL SECTOR FOUND 


; START DELAY TO MIDDLE OF PREAMBLE 


OUT (C) ,D 




OUT (C) ,E 


ENABLE CHANNEL 1 


LD C,CTC2 


ENABLE CHANNEL 2 


OUT (C) ,H 




OUT (C) ,L 




POP HL 


RESTORE REGISTERS 


POP DE 




POP AF 




EI 




RET I 




INT2: PUSH AF 


SAVE REGISTERS 


PUSH BC 




LD A, 3 


• RESET CTC CHANNEL 2 


OUT (CTC2) ,A 




CNTMOD EQU 47 H 




CTRMOD EQU 0C7H 




TIME32 EQU 16H 




DELAY1 EQU 8EH 





5. Several routines are needed to handle the sector 
interrupts via Counter-Timer-Circuit (CTS) programming: 
Routine into generates the time delays; Routine inti 
prepares the CTC; Routine intii handles the polling phase; 
and INT2 resets the CTC. 



middle of the preamble (Fig. 3)— and this point must 
be found with good accuracy. 

A Z80 CTC (counter-timer circuit) may be used to 
generate floppy-disk controller interrupts. In this 
application, three of its four programmable counters 
are needed. 

Counter channel 1 is driven by a 1.4056-jus periodic 
signal (derived from a standard 11.3828-MHz crystal 
oscillator, divided by 16) that is programmed to count 
22 ( = 16h) such pulses. The counter, therefore, reaches 
a full count every 32 /us, which corresponds to the 
length of 1 byte. 

The second counter is driven in cascade by the first 
counter's output (pin 9) and programmed to generate 
an interrupt after a varying number of byte units on 
pin 12 (line INT). 

The sector pulse line from the floppy drive is 
connected to the counter input of CTC channel (pin 
23) to generate an interrupt on any desired sector. The 
sector pulse line is also connected to a Z80 PIO bit 
on this same controller so that the presence of a sector 
hole may be detected by a simple port read followed 
by a bit test. 

Several routines are used in the sector-read opera- 
tion of a typical hard-sectoring floppy-disk driver. The 
program (Fig. 5) assumes that the number of holes 
between the current sector and the requested sector 
has been computed in a previous routine, the result 
being held in a variable named COUNT. 

The interrupt routines generate the proper delay to 
look for the sector hole— not of the sector to be read, 
but the one before. Then the program adds 0.9 times 
the length of a sector and, at that moment, switches 
from an interrupt to a polling technique. This ap- 
proach assures that the CPU can execute other tasks 
as long as possible, without running the risk of missing 
a sector hole. 

It would have been simpler to program the Z80 CTC 
to interrupt on the requested sector hole rather than 
on the previous one. In that case, however, the 
interrupt overhead delay, added to the time required 
to preserve registers and flags and to set up the Z80 
CTC time delay, would be in the order of 186 T states 
(Fig. 6). 

If the controller must operate both on a 2.5-MHz 
(Z80) and a 4-MHz (Z80A) processor, the described 
method becomes unacceptable because the variable 
overhead time between the moment the sector pulse 
occurs and the moment the preamble-delay 
countdown starts. Instead, the sector hole is detected 
by software polling, which only introduces a CPU 
clock-dependent delay of 86 to 101 T states (Fig. 7). 
The polling loop, however, is entered about 4.5 ms after 
the previous hole has been encountered, to return 
control to the main program for as long as possible. 

Polling and interrupt techniques can be combined 
in this case because sector holes are regularly spaced 
on a disk. Knowing when one hole flies by is, in theory, 
enough to predict the start of any following sector; 
in practice, however, speed variation, electrical delays 
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T-STATES 


FUNCTION 


21 


Max. Interrupt detection delay 




("longest Z-80 CPU instruction time) 


19 


Interrupt acknowledge delay 


11 


PUSH AF ; SAVE FLAGS, REGISTERS 


11 


PUSH HL 


11 


PUSH DE 


11 


PUSH BC 


20 


PUSH IY 


7 


LD C,CTC1 


10 


LD DE,CNTMOD.SHL.8+TIME32 


10 


LD HL,CTRMOD.SHL.8+DELAY2 


12 


OUT (C) ,D 


12 


OUT (C) ,E ; ENABLE CHANNEL 1 


7 


LD C,CTC2 ; ENABLE CHANNEL 2 


12 


OUT (C) ,H 


12 


OUT (C) ,L 


186 


Total number of T states 



6. Timing analysis shows that detecting sectors purely by 
interrupts requires 186 T states— too much for a CPU- 
clock-independent floppy controller. 



T STATES FUNCTION 

11 INT11: IN A,(PIOB) ; SEE FIGURE 4 
8 BIT SECTOR, A 

12 TO 27 JR NZ,INT11 ; SEE NOTE 
12 OUT (C),D 

12 OUT (C) ,E ; ENABLE CHANNEL 1 

7 LD C,CTC2 ; ENABLE CHANNEL 2 

12 OUT (C) ,H 

12 OUT (C),L 

86 TO 101 Total number of T states 

NOTE: If sector pulse occurs after execution of input 
instruction, loop is entered up to 15 T states later. 



7. Detecting sectors by polling takes less time; the exact 
number of T states depends on the timing of the sector 
pulse with respect to program execution. 

and mechanical delays introduce too many uncertain- 
ties. Still, the approximate knowledge of the requested 
hole's occurrence permits the calling program to 
utilize additional CPU time before the polling loop for 
sector-hole sensing takes over. This provides the 
preamble delay-time count with an accurate starting 
point. 

The presence of one index hole on the disk, whose 
position with respect to the first encountered hole is 
not known, requires special attention. When the Z80 
CTC interrupts, its internal counter is reloaded and 
remains enabled, and any pulse on the Z80 CTC input 
line will decrement the counter, even though the device 
may not have left the interrupt state. To avoid 
spurious interrupts from the index hole, the Z80 CTC 
is always reset in all Z80 CTC interrupt-service 
routines, even though this may not always be neces- 
sary ■■ 

How useful? Circle No. 

Immediate design application 550 

Within the next year 551 

Not applicable 552 
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Introduction The Zilog Z8000 CPU microprocessor is a 

major advance in microcomputer architecture. 
It offers many minicomputer and mainframe 
features for the first time in a microprocessor 
chip. This tutorial describes the Z8000 CPU 
with emphasis placed on those features that set 
it apart from its microprocessor predecessors. 
For a detailed description of all Z8000 CPU 
features, consult the Zilog publications listed 
in the bibliography at the end of this tutorial. 

The features to be discussed are grouped 
into four areas: CPU organization, handling of 
interrupts and traps, use of memory, and new 



instructions and data capabilities. 

Before discussing these features in more 
detail, a word about nomenclature is in order. 
The term Z8000 refers to the concept and 
architecture of a family of parts. Zilog has 
adopted the typical conductor industry 4-digit 
designation for Z8000 Family parts, while also 
keeping the traditional 3- letter acronym that 
proved so popular for the Z-80 Family. Thus, 
the 48-pm version of the Z8000 CPU is called 
the Z8001 CPU; the 40-pin version is known as 
the Z8002 CPU. 



CPU The Z8000 CPU is organized around a 

Organization general-purpose register file (Figure 1). The 
register file is a group of registers, any one 
of which can be used as an accumulator, 
index register, memory pointer, stack pointer, 
etc. The only exception is Register 0, as 
explained later. 

Flexibility is the major advantage of a 
general-purpose register organization over an 
organization that dedicates particular registers 
to each function. Computation-oriented 
routines can use general registers as 
accumulators for intermediate results whereas 
data manipulation routines can use these 
registers for memory pointers. 

Dedicated registers, however, have a disad- 
vantage: when more registers of a given type 
are needed than are supplied by the machine, 
the performance degrades by the extra instruc- 
tions to swap registers and memory locations. 
For example, a processor with two index 
registers suffers when three are needed 
because a temporary variable in memory (or in 
another register) must be used for the third 



index. When the third index is needed, it must 
be swapped into an index register. In contrast, 
on a general-register machine three of the 
registers could be dedicated for index use. In 
addition, since the need for index registers 
may vary over the course of a program, a 
general-register architecture, such as the 
Z8000, can be adapted to the changing needs 
of the computation with respect to the number 
of accumulators, memory pointers and index 
registers. Thus flexibility results in increased 
performance and ease of use. 

In addition, the registers of the Z8000 are 
organized to process 8-bit bytes, 16-bit words, 
32-bit long words and 64-bit quadruple words. 
This readily accommodates applications that 
process data of variable sizes as well as dif- 
ferent tasks that require different data sizes. 

Although all registers can — in general — be 
used for any purpose, certain instructions such 
as Subroutine Call and String Translation 
make use of specific registers in the general 
register file, and this must be taken into 
account when these instructions are used. 
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Figure 1. CPU Organization 



CPU The Z8000 CPU also contains a number of 

Organization special-purpose registers in addition to the 
(Continued) general-purpose ones. These include the Pro- 
gram Counter, Program Status registers and 



the Refresh Counter. These registers are 
accessible through software and provide some 
of the interesting features of Z8000 CPU 
architecture. 
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Figure 2. Z8001 General Purpose Registers 



Figure 3. Z80O2 General Purpose Registers 



Register All general-purpose registers can be used as 

Organization accumulators, and all but one as index 

registers or memory pointers. The one register 
that cannot be used as an index register is 
Register 0. Specifying Register is used as an 
escape mechanism to change the address mode 
from IR to IM, from X to DA, or — with Load 
instructions — from BA to r)A. This has been 
done so that the two addressing mode bits in 
the instruction can specify more than four 
addressing modes for the same opcode. 

The Z8000 CPU register file can be 
addressed in several groupings: as sixteen 
byte registers (occupying the upper half of the 
file only), as sixteen word registers, as eight 
long-word registers, as four quadruple-word 
registers, or as a mixture of these. Instructions 
either explicitly or implicitly specify the type 
of register. Table 1 illustrates the cor- 
respondence between the 4-bit source and 
destination register fields in the instruction 
(Figure 4) and the location of the registers in 
the register file (Figures 2 and 3). 



Register 
Designator 


Byte 


Word 


Long 
Word 


Quadruple 
Word 


0000 


RH0 


R0 


RR0 


RQ0 


000 1 


RH1 


Rl 






00 1 


RH2 


R2 


RR2 




00 11 


RH3 


R3 






1 00 


RH4 


R4 


RR4 


RQ4 


10 1 


RH5 


R5 






110 


RH6 


R6 


RR6 




111 


RH7 


R7 






1 000 


RL0 


R8 


RR8 


RQ8 


100 1 


RL1 


R9 






10 10 


RL2 


R10 


RR10 




10 11 


RL3 


Rll 






1100 


RL4 


R12 


RR12 


RQ12 


110 1 


RL5 


R13 






1110 


RL6 


R14 


RR14 




1111 


RL7 


R15 







Table 1 
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Register Note that the byte register-addressing 

Organization sequence (most significant bit distinguishes 
(Continued) between the two bytes in a word register) is 
different from the memory addressing 
sequence (least significant bit distinguishes 
between the two bytes in a word). Long-word 
(32-bit) and quadruple-word (64-bit) registers 
are addressed by the binary number of their 
starting word registers (most significant word). 
For example, RR6 is addressed by a binary 6 
and occupies word registers 6 and 7. 
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MODE ♦ 

REGISTER 1 

IMMEDIATE 

DIRECT 

INDIRECT 

INDEXED 



FOR SOURCE = 0000 
I FOR SOURCE * 



Figure 4. Instruction Format 



System/ The Z8000 CPU can run in one of two 

Normal Mode modes: System or Normal. In System Mode, 
of Operation all of the instructions can be executed and all 
of the CPU registers can be accessed. This 
mode is intended for use by programs that per- 
form operating system type functions. In Nor- 
mal Mode, some instructions, such as I/O 
instructions, are not all allowed, and the con- 
trol registers of the CPU are inaccessible. In 
general, this mode of operation is intended for 
use by application programs. This separation 
of CPU resources promotes the integrity of the 
system since programs operating in Normal 
Mode cannot access those aspects of the CPU 
which deal with time- dependent or system 
interface events. 

Normal Mode programs that have errors can 
always reproduce those errors for debug- 
ging purposes by simply re-executing the pro- 
grams with their original data. Programs using 
facilities available only in System Mode may 
have errors due to timing considerations (e.g., 



based on the frequency of disk requests and 
disk arm position) that are harder to debug 
because these errors are not easily repro- 
duced. Thus a preferred method of program 
development would be to partition the task into 
that portion which can be performed without 
recourse to resources accessible only in 
System Mode (which will usually be the bulk of 
the task) and that portion requiring System 
Mode resources. The classic example of this 
partitioning comes from current minicomputer 
and mainframe systems: the operating system 
runs in System Mode and the individual users 
write their programs to run in Normal Mode. 

To further support the System/Normal Mode 
dichotomy, there are two copies of the stack 
pointer — one for the System Mode and another 
for Normal. Although the stacks are separated, 
it is possible to access the normal stack 
registers while in the System Mode by using 
the LDCTL instruction. 



Status Lines The Z8000 CPU outputs status information 

over its four status lines_(STo-ST3) and the 
System/Normal line (S/N). This information can 
be used to extend the addressing range or to 
protect accesses to certain portions of memory. 
The types of status information and their codes 
are listed in Table 2. 

Status conditions are mutually exclusive and 
can, therefore, be encoded without penalty. 
Most status definitions are self-explanatory. 
One code is reserved for future enhancements 
of the Z8000 Family. 

Extension of the addressing range is accom- 
plished in a Z8000 system by allocating 
physical memory to specific usage (program 
vs. data space, for example) and using exter- 
nal circuitry to monitor the status lines and 
select the appropriate memory space for each 
address. For example, the direct addressing 
range of the Z8002 CPU is limited to 64K 
bytes; however, a system can be configured 



with 128K bytes if additional logic is used, 
say, to select the lower 64K bytes for program 
references and the upper 64K bytes for data 
references. 



ST3-ST0 



Definition 



Internal operation 

1 Memory refresh 

10 I/O reference 

11 Special I/O reference 

10 Segment trap acknowledge 

10 1 Non-maskable interrupt acknowledge 

110 Non-vectored interrupt acknowledge 

111 Vectored interrupt acknowledge 

10 Data memory reguest 

10 1 Stack memory reguest 

10 10 Data memory reguest (EPU) 

10 11 Stack memory reguest (EPU) 

110 Instruction space access 

110 1 Instruction fetch, first word 

1110 Extension processor transfer 

1111 Reserved 



Table 2 
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Status Lines Protection of memory by access types is 

(Continued) accomplished similarly. The memory is divided 
into blocks of locations and associated with 
each block is a set of legal status signals. For 
each access to the memory, the external circuit 
checks whether the CPU status is appropriate 
for the memory reference. The Z8010 Memory 
Management Unit is an example of an external 
memory-protection circuit, and it is discussed 
later in this tutorial. 

The first word in an instruction fetch has its 



own dedicated status code, namely 1101. This 
allows the synchronization of external circuits 
to the CPU. During all subsequent fetch cycles 
within the same instruction (remember, the 
longest instruction requires a total of four word 
fetches), the status is changed from 1101 to 
1100. Load Relative and Store Relative also 
have a status of 1100 with the data reference, 
so information can be moved from program 
space to data space. 



Refresh The idea of incorporating the Refresh 

Counter in the CPU was pioneered by the 
Z-80 CPU, which performs a refresh access in 
a normally unused time slot after each opcode 
fetch. The Z8000 is more straightforward (each 
refresh has its own memory-access time slot of 
three clock cycles), and is more versatile (the 
refresh rate is programmable and capable of 
being disabled altogether). 

The Refresh Register contains a 9-bit Row 
Counter, a 6-bit Rate Counter and an Enable 
Bit (Figure 5). The row section is output on 
ADq-AD8 during a refresh cycle. The Z8000 
CPU uses word- organized memory, wherein Ao 
is only employed to distinguish between the 
lower and upper bytes within a word during 
reading or writing bytes. Ao therefore plays no 
role in refresh — it is always 0. The Row 
Counter is — at least conceptually — always 
incremented by two whenever the rate counter 
passes through zero. The Row Counter cycles 
through 256 addresses on lines ADi-ADs, 
which satisfies older and current 64- and 
128- row addressing schemes, and can also be 
used with 256-row refresh schemes for 
64K RAMs. 

The Rate Counter determines the time 
between successive refreshes. It consists of a 
programmable 6-bit modulo-n prescaler 



(n = 1 to 64), driven at one-fourth the CPU 
clock rate. The refresh period can be pro- 
grammed from 1 to 64 fis with a 4 MHz clock. 
A value of zero in the counter field indicates 
the maximum time between refreshes; a value 
of n indicates that refresh is to be performed 
every 4n clock cycles. Refresh can be disabled 
by programming the Refresh Enable Bit to 
be zero. 

A memory refresh occurs as soon as possible 
after the indicated time has elapsed. Gener- 
ally, this means after the T3 clock cycle of an 
instruction if an instruction execution has com- 
menced. When the CPU does not have control 
of the bus (during the bus-request/bus- 
acknowledge sequence, for example), it cannot 
issue refresh commands. Instead, it has inter- 
nal circuitry to record "missed" refreshes; 
when the CPU regains control of the bus it 
immediately issues the "missed" refresh cycles. 
The Z8001 and Z8002 CPU can record up to 
two "missed" refresh cycles. 
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Figure 5. Refresh Counter 



Instruction Most instructions conclude with two or three 

Prefetch clock cycles being devoted to internal CPU 

(Pipelining) operations. For such instructions, the sub- 
sequent instruction-fetch machine cycle is 
overlapped with the concluding operations, 
thereby improving performance by two or 
three clock cycles per instruction. 

Examples of instructions for which the sub- 
sequent instruction is fetched while they com- 
plete are Arithmetic and Shift instructions. 



Some instructions for which the overlap is 
logically impossible are the Jump instructions 
(because the following instruction location has 
not been determined until the instruction com- 
pletes). Some instructions for which overlap is 
physically impossible are the Memory Load 
instructions (because the memory is busy with 
the current instruction and cannot service the 
fetch of the succeeding instruction). 
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Extended The Z8000 architecture has a mechanism for 

Instruction extending the basic instruction set through the 
Facility use of external devices. Special opcodes have 

been set aside to implement this feature. When 
the CPU encounters instructions with these 
opcodes in its instruction stream, it will per- 
form any indicated address calculation and 
data transfer, but otherwise treat the ''extended 
instruction" as being executed by the external 
device. Fields have been set aside in these 
extended instructions which can be interpreted 
by external devices (called Extended Process- 
ing Units — EPUs) as opcodes. Thus by using 
appropriate EPUs, the instruction set of the 
Z8000 can be extended to include specialized 
instructions. 

In general, an EPU is dedicated to perform- 
ing complex and time consuming tasks in 
order to unburden the CPU. Typical tasks 
suitable for specialized EPUs include floating- 
point arithmetic, data base search and 
maintenance operations, network interfaces, 
graphics support operations — a complete list 
would include most areas of computing. EPUs 
are generally designed to perform their tasks 
on data resident in their internal registers. 
Moving information into and out of the EPU's 
internal registers, as well as instructing the 
EPU as to what operations are to be per- 
formed, is the responsibility of the CPU. 

For the Z8000 CPU, control of the EPUs 
takes the following form. The Z8000 CPU 
fetches instructions, calculates the 
addresses of operands residing in memory, 
and controls the movement of data to and 
from memory. An EPU monitors this activity on 
the CPU's AD lines. If the instructions fetched 
by the CPU are extended instructions, all 
EPUs and the CPU latch the instruction (there 
may be several different EPUs controlled by 
one CPU). If the instruction is to be executed 
by a particular EPU, both the CPU and the 
indicated EPU will be involved in executing 
the instruction. 

If the extended instruction indicates a 
transfer of data between the EPU's internal 
registers and the main memory, the CPU will 
calculate the memory address and generate 
the app ropriate timing signals (AS, DS, 
MREQ, etc.), but the data transfer itself is 
between the memory and the EPU (over the 



AD lines). If a transfer of data between the 
CPU and EPU is indicated, the sender places 
the data on the AD lines and the receiver 
reads the AD lines during the next clock 
period. 

If the extended instruction indicates an 
internal operation to be performed by the EPU, 
the EPU begins execution of that task and the 
CPU is free to continue on to the next instruc- 
tion. Processing then proceeds simultaneously 
on both the CPU and the EPU until a second 
extended instruction is encountered that is 
destined for the same EPU (if more than one 
EPU is in the system, all can be operating 
simultaneously and independently). If an 
extended instruction specifies an EPU still 
executing a previous extended instruction, the 
EPU can suspend instruction fetching by the 
Z8000 CPU until it is ready to accept the next 
ext ended instruction: the mechanism for this is 
the STOP line, which suspends CPU activity 
during the instruction fetch cycle. 

There are four types of extended instructions 
in the Z8000 CPU instruction repertoire: EPU 
internal operations; data transfers between 
memory and EPU; data transfers between EPU 
and CPU; and data transfer between EPU flag 
registers and CPU flag and control word. The 
last type is useful when the program must 
branch based on conditions determined by the 
EPU. Six opcodes are dedicated to extended 
instructions: OE, OF, 4E, 4F, 8E and 8F (in 
hexadecimal) . The action taken by the CPU 
upon encountering these instructions is depen- 
dent upon an EPU control bit in the CPU's 
FCW. When this bit is set, it indicates that the 
system configuration includes EPUs; therefore, 
the instruction is executed. If this bit is clear, 
the CPU traps (extended instruction trap), so 
that a trap handler in software can emulate the 
desired operation. 

In conclusion, the major features of this 
capability are, that multiple EPUs can be 
operating in parallel with the CPU, that the 
five main CPU addressing modes (Register, 
Immediate, Indirect Register, Direct Address, 
Indexed) are available in accessing data for 
the EPU; that each EPU can have more than 
256 different instructions; and that data types 
manipulated by extended instructions can be 
up to 16 words long. 
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Program The Program Status Information consists of 

Status the Flag And Control Word (FCW) and the 

Information Program Counter (PC). The Z8000 CPU uses 

one byte in FCW to store flags and another 

byte to store control bits. 

Arithmetic Flags. Flags occupy the low byte 
in the FCW and are loaded, read, set and 
reset by the special instruction LDCTLB, 
RESFLG and SETFLG. The flags are: 

C Carry 

Z Zero 

S Sign (1 = negative; two's complement 
notation is used for all arithmetic on 
data elements) 

P/V Even Parity or Overflow (the same bit is 
shared) 

D Decimal Adjust (differentiates between 
addition and subtraction) 

H Half Carry (from the low-order nibble) 



Control Bits. The control bits occupy the 
upper byte in the FCW. They are loaded and 
read by the LDCTL instruction, which is 
privileged in that it can be executed only in 
the System Mode. The control bits are: 

NVIE Non- Vectored Interrupt Enable 

VIE Vectored Interrupt Enable 

S/N System or Normal Mode 

SEG Segmented Mode Enable (Z8001 only) 

The SEG bit is always in the Z8002 even if 
the programmer attempts to set it. In the 
Z8001, a 1 in this bit indicates segmented 
operation. A in the Z8001 SEG bit forces 
non- segmented operation and the CPU inter- 
prets all code as non- segmented. Thus, the 
Z8001 can execute modules of user code 
developed for the non- segmented Z8002. 



Interrupt The Z8000 provides a powerful interrupt and 

and Trap trap structure. Interrupts are external asyn- 

Structure chronous events requiring CPU attention, and 

are generally triggered by peripherals needing 
service. Traps are synchronous events 
resulting from the execution of certain instruc- 
tions. Both are processed in a similar manner 
by the CPU. 

The CPU supports three types of interrupts 



(non-maskable, vectored and non- vectored) , 
three internal traps (system call, unimple- 
mented instruction, privileged instruction) and 
a segmentation trap. The vectored and non- 
vectored interrupts are maskable. 

The descending order of priority for traps 
and interrupts is: internal traps, non-maskable 
interrupts, segmentation trap, vectored inter- 
rupts and non- vectored interrupts. 



Effects of The Flag and Control Word and the Pro- 

Interrupts gram Counter are collectively called the Pro- 

on Program gram Status Information — a useful grouping 
Status because both the FCW and PC are affected by 

interrupts and traps. When an interrupt or trap 
occurs, the CPU automatically switches to the 
System Mode and saves the Program Status 
plus an identifier word on the system stack. 
The identifier supplies the reason for the inter- 
rupt. (The Z8002 pushes three words on the 
stack; the Z8001 pushes four words.) 

After the pre- interrupt or "old" Program 
Status has been stored, the u new" Program 
Status is automatically loaded into the FCW 
and PC. This new Program Status Information 
is obtained from a specified location in 
memory, called the Program Status Area. 

The Z8000 CPU allows the location of the 
Program Status Area anywhere in the address- 
able memory space, although it must be 
aligned to a 256-byte boundary. Because the 
Status Line code is 1100 (program reference) 
when the new Program Status is loaded, the 
Program Status must be located in program 
memory space if the memory uses this attribute 
(for example, when using the Z8010 Memory 
Management Unit or when separate memory 
modules are used for program and for data). 



The Program Status Area Pointer (PSAP) 
specifies the beginning of the Program Status 
Area. In the Z8002, the PSAP is stored in one 
word, the lower byte of which is zero. The 
Z8001, however, stores its PSAP in two words. 
The first contains the segment number and the 
second contains the offset, the lower byte of 
which is again zero. The PSAP is loaded and 
read by the LDCTL instruction. 

In the Z8002, the first 14 words (28 bytes) of 
the Program Status Area contain the Program 
Status Information for the following interrupt 
conditions: 



Location 
(In Bytes) 


Condition 


0-3 


Not used (reserved for future use) 


4-7 


Unimplemented instruction has 
been fetched, causing a trap 


8-11 


Privileged instruction has been 
fetched in Normal Mode, causing a 
trap 


12-15 


System Call instruction 


16-19 


Not used 


20-23 


Non-maskable interrupt 


24-27 


Non- vectored interrupt 
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Effects of Bytes 28-29 contain the FCW that is corn- 

Interrupts mon to all vectored interrupts. Subsequent 

on Program locations contain the vector jump table (new 
Status PC for vectored interrupts). These locations 

(Continued) are addressed in the following way: the 8- bit 
vector that the interrupting device has put on 
the lower byte of the Address/Data bus 
(AD0-AD7) is doubled and added to 
PSAP + 30. Thus, 

Vector addresses PSAP -I- 30, 
Vector 1 addresses PSAP + 32, and 
Vector 255 addresses PSAP + 540. 

In the segmented Z8001, the first 28 words of 
the Program Status Area (56 bytes) contain the 
Program Status Information (reserved word, 
FCW, segment number, offset), for the follow- 
ing interrupt conditions: 



Bytes 56-59 contain the reserved word and 
FCW common to all vectored interrupts. 
Subsequent locations contain the vector jump 
table (the new segment number and offset for 
all vectored interrupts). These locations are 
addressed in the following way: the 8- bit vec- 
tor that the interrupting device has put on the 
lower byte of the Address/Data bus (AD0-AD7) 
is doubled and added to PSAP + 60. Thus, 

Vector addresses PSAP + 60, 
Vector 2 addresses PSAP + 64, and 
Vector 254 addresses PSAP + 568. 

Care must be exercised in allocating vector 
locations to interrupting devices; always use 
even vectors. Thus there are effectively only 
128 entries in the vector jump table. (Figure 6 
illustrates the Program Status Area.) 



Location 
(In bytes) 


Condition 


Z8002 OFFSET „ 
(IN BYTES) ° 

4 

8 

12 

16 

20 

24 

28 
30 
32 
34 
36 


88SSfi¥*E0 


„ Z8001 OFFSET 
(IN BYTES) 


mmxmtm 
mrnvmncm 


8 




Not used (reserved for future use) 

Unimplemented instruction has 
been fetched causing a trap 

Privileged instruction has been 
fetched in Normal Mode causing 
a trap 

System Call instruction 

Segmentation trap (memory viola- 
tion detected by the Z8010 Memory 
Management Unit) 

Non-maskable interrupt 




0-7 




16 


8-15 




24 




smmw trap * 

(UNUSED FOR ZB002) 


32 


16-23 


NON-MASSABiE 

wtmem 


40 




m&mttam ' 
mvamm 


48 


24-31 




56 
60 


32-39 


> WWK , '■ 


64 




"I 






72 


40-47 




> INTERRUPT 
I JUMP TABLE 


■WSWPC 





48-55 



Non- vectored interrupt 



Figure 6. Program Status Area 
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Z8000 CPU The way a processor addresses and manages 

Memory its memory is an important aspect in both the 

Features evaluation of the processor and the design of a 

computer system that uses the processor. Z8000 
architecture provides a consistent memory 
address notation in combining bytes into words 
and words into long words. All three data 
types are supported for operands in the Z8000 
instruction set. I/O data can be either byte- or 
word-oriented. 

The Z8001 CPU provides a segmented 
addressing space with 23-bit addressing. The 
Z8010 Memory Management Unit can increase 
the address range of this processor. To support 
a memory management system, the Z8001 pro- 
cessor generates Processor Status Information. 



These signals are also generated by the Z8002 
CPU and — as mentioned earlier — can be used 
to increase the address range of this processor 
beyond its nominal 64K byte limit. It is not 
necessary to use a Z8010 Memory Management 
Unit with a Z8001. The segment number (upper 
six bits of the address) can be used directly by 
the memory system as part of the absolute 
address. 

These issues are discussed in more detail in 
the following sections, along with a descrip- 
tion of the method used to encode certain 
segmented addresses into one word. A brief 
comment on the use of 16K Dynamic RAMs 
with the Z8001 concludes this group of sections 
that deal with Z8000 CPU memory features. 



Address In the Z8000 CPU, memory and I/O 

Notation addresses are always byte addresses. Words or 

long words are addressed by the address of 
their most significant byte (Figure 7). Words 
always start on even addresses (Aq = 0), so 
both bytes of a word can be accessed simul- 
taneously. Long words also start on even 
addresses. 

Within a word, the upper (or more signifi- 
cant) byte is addressed by the lower (and 
always even) address. Similarly, within a long 
word, the upper (more significant) word is 
addressed by the lower address. Note that this 
format differs from the PDP- 1 1 but is identical 
to the IBM convention. 

There is good reason for choosing this for- 
mat. Because the Z8000 CPU can operate on 
32-bit long words and also on byte and word 
strings, it is important to maintain a continuity 
of order when words are concatenated into 
long words and strings. Making ascending 
addresses proceed from the highest byte of the 
first word to the lowest byte of the last word 
maintains this continuity, and allows compar- 



ing and sorting of byte and word strings. 

Bit labeling within a byte does not follow this 
order. The least significant bit m a byte, word 
or long word is called Bit and occurs in the 
byte with the highest memory address. This is 
consistent with the convention where bit n 
corresponds to position 2 n in the conventional 
binary notation. This ordering of bit numbers 
is also followed in the registers. 



WORD 
ADDRESSES A 


BYTE 
DDRESSES M 

0000 
0001 
0010 
0011 
0100 
0101 
0110 
0111 
1000 
1001 


EMORY 


0000 1 


A0 




5B 




0010 I 


C2 




35 




0100 I 


02 




AB 




0110 I 


2B 




FF 




1000 I 


A2 









CONTENTS OF BYTE 0100 = "02" 

CONTENTS OF WORD 0100 = "02AB" 

CONTENTS OF LONG WORD 0100 = "02AB2BFF" 

CONTENTS OF LONG WORD 0010 = "C23502AB" 



Figure 7. Memory Addressing 
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Memory Like most 16-bit microprocessors, the Z8000 

and I/O CPU uses a 16-bit parallel data bus between 

Addressing the CPU and memory or I/O. The CPU is 
capable of reading or writing a 16-bit word 
with every access. Words are always addressed 
with even addresses (Ao = 0). All instructions 
are words or multiple words. 

The Z8000 CPU can, however, also read and 
write 8-bit bytes, so memory and I/O addresses 
are_always expressed in bytes. The Byte/Word 
(B/W) output indicates whether a byte or word 
is addressed (High = byte). Ao distinguishes 
between the upper and lower byte in memory 
or I/O. The most significant byte of the word is 
addressed when Ao is Low (Figure 8). 

For word operations in both the read and 
write modes, B/W = Low, Aq is simply 



ignored and A1-A15 address the memory or 
I/O^ For byte operations in the read mode, 
B/W = High, Ao is again ignored, and a 
whole word (both bytes) is read, but the CPU 
internally selects the appropriate byte. For 
byte operations in the write mode, the CPU 
outputs identical information on both the Low 
(AD0-AD7) and the High (AD 8 -ADi 5 ) bytes of 
the Address/Data bus. External TTL logic must 
be used to enable writing in one memory byte 
and disable writing in the other byte, as 
defined by Ao- The replication of byte informa- 
tion for writes is for the current implementation 
and may change for subsequent Z8000 CPUs; 
therefore system designs should not depend 
upon this feature. 



16-BIT BUS DATA PATH 



o 



S DRIVER RECEIVERS 
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WORD \ 

ADDRESS / 



H 



B¥Ti 
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P^ 



H 
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BYTE 
BANK 
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BANK 
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m> 



LOWER 

BANK 

ENABLE 



Figure 8. Byte/ Word Selection 



Segmentation In organizing memory, segmentation is a 

powerful and useful technique because it forms 
a natural way of dividing an address space into 
different functional areas. A program typically 
partitions its available memory into disjointed 
areas for particular uses. Examples of this are 
storing the -procedure instructions, holding its 
global variables, or serving as a buffer area 
for processing large, disk-resident data bases. 
The requirements for these different areas may 
differ, and the areas themselves may be 
needed only part of the time. 

Segmentation reflects this use of memory by 
allowing a user to employ a different segment 
for each different area. A memory manage- 
ment system can then be employed to provide 
system support, such as swapping segments 
from disk to primary memory as requested (as 
in overlays), or in monitoring memory accesses 
and allowing only certain types of accesses to 



a particular segment. Thus, dealing with 
segments is a convenient way of specifying 
portions of a large address space. 

When segmentation is combined with an 
address translation mechanism to provide 
relocation capability, the advantages of 
segmentation are enhanced. Now segments can 
be of variable user- specifiable sizes and 
located anywhere in memory. 

The Z8001 generates 23-bit logical 
addresses, consisting of a 7-bit segment 
number and a 16-bit offset. Thus each of its six 
memory address spaces consists of 128 seg- 
ments, and each segment can be up to 64K 
bytes. Different routines of a program can 
reside in different segments, and different data 
sets can reside in different segments. The 
Z8010 Memory Management Unit translates 
these logical addresses into physical-memory 
locations. 
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Long Offset When a segmented address is stored in 

and Short memory or in a register, it occupies two 

Offset 16-bit words as previously described for the 

Addressing PC and PSAP. This is a consequence of the 
large addressing range. When a segmented 
address is part of an instruction in the Direct 
Address and Indexed Address Modes, there 
are two representations: Long and Short Offset 
addressing. 

In the general unrestricted case of Long Off- 
set, the segmented address occupies two 
words, as described before. The most signifi- 
cant bit in the segment word is a 1 in this case. 
The Short Offset Mode squeezes the segment 
number and offset into one word, saving pro- 



gram size and execution time. Since 23 bits 
obviously don't fit into a 16-bit word, the 8 
most significant bits of the offset are omitted 
and implied to be zero. The most significant 
bit of the address word is made to indicate 
Short Offset Mode. Short Offset addresses are 
thus limited to the first 256 bytes at the begin- 
ning of each segment. This may appear to be a 
severe restriction, but it is very useful, 
especially in the Index Mode, where the index 
register can always supply the full 16-bit range 
of the offset. Short Offset saves one instruction 
word and speeds up execution by two clock 
cycles in Direct Address Mode and three clock 
cycles in Indexed Mode. 



Using the The Z8001 CPU can be combined with 

Z8010 Mem- another 48-pin LSI device— the Z8010 MMU— 
ory Manage- for sophisticated memory management. The 
ment Unit MMU provides address translation from the 

logical addresses generated by the Z8001 CPU 
to the physical addresses used by the memory. 
An address translation table, containing start- 
ing addresses and size information for each of 
the 64 segments, is stored in the MMU. The 
translation table can be written and read by 
the CPU using Special I/O instructions. The 
MMU thus provides address relocation under 
software control, making software addresses 
(i.e., logical addresses) independent of the 
physical memory addresses. 

But the MMU provides much more than 
address relocation; it also monitors and pro- 
tects memory access. The MMU provides a 
Trap input to the C PU and — if necessary — an 
inhibit signal (SUP) to the memory write logic 
when specific memory-access violations occur. 
The MMU provides the following types of 
memory protection: 

■ Accesses outside the segment's alloted 
memory can be prevented. 

■ Any segment can be declared invalid or 
non-accessable to the CPU. 

■ Segments can be declared Read Only. 

■ By designating a segment as System Only, 
access can be prohibited during the Normal 
Mode. 

■ Declaring a segment Execute Only means it 
can be accessed only during instruction 
access cycles. Data or stack use is pro- 
hibited. 

■ Any segment can be excluded from DMA 
access. 

■ Segments can have a Direction And Write 
Warning attribute, which generates a trap 
when a write access is made in the last 256 
bytes of its size. This mechanism can be 
used to prevent stack overflow. 



Multiple MMUs must be used when more 
than 64 segments are needed. Thus, to support 
the full complement of 128 segment numbers 
provided for each Z8001 CPU address space, 
two MMUs are required. The MMU has been 
designed for multiple-chip configurations, both 
to support 128- segment translation tables and 
to support multiple translation table systems. 

Note that the memory management features 
do not interfere with the ability to directly 
address the entire memory space. Once pro- 
grammed, the MMU (or MMUs) translates and 
monitors any memory address generated by 
the CPU. 

The MMU contains status bits that describe 
the history of each segment. One bit for each 
segment indicates whether the segment has 
been accessed; another bit indicates whether 
the segment has been written. This is important 
for certain memory management schemes. For 
example, the MMU indicates which segments 
have been updated and, therefore, must be 
saved on disk before the memory can be used 
by another program. 

When translating logical addresses to phys- 
ical memory addresses, the MMU must do the 
following: access its internal 64 x 32-bit RAM, 
using the segment number as the address, then 
add the 16 bits of RAM output to the most 
significant address byte (ADs-ADis) and final- 
ly place the result on its Address outputs. The 
least significant byte (AD0-AD7) bypasses the 
MMU. 

The internal RAM access time is approxi- 
mately 150 ns. Throughput delay is avoided by 
making the segment number available early: 
SN0-SN7 are output one clock period earlier 
than the address information on AD0-AD7. 

In summary, the Z8000 CPU supports 
sophisticated memory management through 
such architectural features as the Status Lines, 
the R/W and S/N lines, Segment Trap input 
line, and early output of segment numbers. 
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Using 16K Z8000 systems usually implement most of 

Dynamic their memory with 16K x 1-bit dynamic RAMs 

RAMs with that have time-multiplexed addresses (Zilog 
the Z8001 also manufactures this device — the Z61 16). 

In Z8001 -based systems with MMUs, CPU 
Address/Data lines AD1-AD7 supply row 
addresses, MMU address outputs As- A 14 sup- 
ply column addresses, and MMU outputs 
A15-A23 are decoded t o gen era te Ch ip Select 
signals th at ga te either RAS or CAS or both. 

Gating RAS reduces power consumption 
because all non- selected memories remain 
in the standby mode. But this technique 



requires that RAS must wait for the availability 
of the most significant add ress b its from the 
MMU. During refresh, the RAS decoder must 
be changed to activate all memories 
simultane ously . 

Gating CAS does not achieve lower power 
consumption; however, this techniq ue all ows 
the use of slower memories because RAS can 
be activated as soon as the CPU address out- 
puts are stable, without waiting for the MMU 
delay . Also, there is no need to change the 
CAS decoder during refresh. 



Data Types The Z8000 architecture directly supports 

and bits, digits, bytes, and 16- or 32-bit integers as 

Instructions primitive operands in its instruction set. In 

addition, the rich set of addressing modes sup- 
ports higher- level data constructs such as 
arrays, lists and records. The Z8000 also intro- 



duces a number of powerful instructions that 
extend the capabilities of microprocessors. The 
remaining sections of this paper describe 
Z8000 data types, addressing modes, and a 
selection of novel instructions. 



ids are 1, 4, 8, 16, 32, or 64 bits, as 
specified by the instruction. In addition, 
strings of 8- or 16-bit data can be manipulated 
by single instructions. Of particular interest 
are the increased precisions of the arithmetic 
instructions. Add and Subtract instructions can 



operate on 8-, 16-, or 32-bit operands: Multi- 
ply instructions can operate on 16- or 32-bit 
multiplicands; and Divide instructions can 
operate on 32- or 64-bit dividends. The Shift 
instructions can operate on 8-, 16-, and 32-bit 
registers. 



Addressing The rich variety of addressing modes offered 

Modes by Z8000 architecture includes: Register, 

Immediate, Indirect Register, Direct Address, 
Index, Relative Address, Base Address, and 
Base Index. Three are of particular interest 
with respect to high-level data structures: 
Indirect Register, Base Address, and Base 
Index. These modes can be used for lists, 
records, and arrays, respectively. 

Indirect Register. In this addressing mode, 
the contents of the register are used as a 
memory address. This mode is needed 
whenever special address arithmetic must be 
performed to reference data. Essentially, the 
address is calculated in a register and then 
used to fetch the data. For example, this mode 
is useful when manipulating a linked list, 
where each entry contains a memory pointer to 
the memory location of the next entry. Essen- 
tially, the pointer is loaded into a register and 
used to access the next item on the list. When 
the list item is large or has a complex struc- 
ture, the Base Address or Base Index Modes 
can be used to access various components of 
the item. 

Base Address. In this addressing mode, the 
memory address contained in the register (the 
base) is modified by a displacement in the 
instruction (known at compile time). This mode 



is useful, for example, in accessing fields 
within a record whose format is fixed at com- 
pile time. 

Base Index. The memory address in this 
addressing mode is contained in a register (the 
base) and is modified by the contents of 
another register (the index). This mode can be 
useful in accessing the components of an 
array, because the index of the component is 
usually calculated during execution time — as a 
function of the index of a DO-Loop, for 
example. 

Index vs. Base Address. In the Z8002 and in 
the Z8001 running non- segmented, these two 
addressing modes are functionally equivalent, 
because the base address and displacement 
are both 16-bit values. 

When the Z8001 runs segmented, there is a 
difference: in the Index mode, the base 
address (including the segment number) is 
contained in the instruction, in either Short 
Offset or Long Offset notation. The 16-bit dis- 
placement stored in a register is then added to 
the offset in the base address to calculate the 
effective address. In the Base Address Mode, 
on the other hand, the 16-bit displacement is 
specified in the instruction and is added to the 
offset of the base address that is stored in a 
long- word register. 
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The Instruc- The Z8000 offers an abundant instruction set 

tion Set that represents a major advance over its 

predecessors. The Load and Exchange instruc- 
tions have been expanded to support operating 
system functions and conversion of existing 
microprocessor programs. The usual Arith- 
metic instructions can now deal with higher- 
precision operands, and hardware Multiply 
and Divide instructions have been added. The 
Bit Manipulation instructions can access a 
calculated bit position within a byte or word, 
as well as specify the position statically in the 
instruction. 

The Rotate and Shift instructions are con- 
siderably more flexible than those in previous 
microprocessors. The String instructions are 
useful in translating between different 
character codes. Special I/O instructions are 
included to manage peripheral devices, such 
as the Memory Management Unit, that do not 
respond to regular I/O commands. Multiple- 
processor configurations are supported by 
special instructions. 

The following instructions exemplify the 
innovative nature of the Z8000 instruction set. 
A complete list of Z8000 instructions can be 
found in the reference materials listed at the 
end of this tutorial. 

Load and Exchange Instructions. 

Exchange Byte (EX) is practical for converting 
Z-80, 8080, 6800 and other microprocessor 
programs into Z8000 code, because the Z8000 
uses the opposite assignment of odd/even 
addresses in 16-bit words. 

Load Multiple (LDM) saves n registers and is 
useful for switching tasks. 

Load Relative (LDR) loads fixed values from 
program space into data space. 

Arithmetic Instructions. 

Add With Carry and Subtract With Carry 
(ADC, SBC) are conventionally used in 8-bit 
microprocessors for multiprecision arithmetic 
operations. These instructions are rarely used 
with the Z8000 CPU because it has 16- and 
32-bit arithmetic instructions. 

Decrement By N and Increment By N (DEC, 
INC) are intended for address and pointer 
manipulation, but can also be used for Quick 
Add/Subtract Immediate with 4-bit nibbles. 
The flag setting is different from Add/Subtract 
instructions — as is conventional — in that the 
Carry and Decimal adjust flags are unaffected 
by the Increment and Decrement instructions 
to support multiple precision arithmetic. 

Decimal Adjust (DAB) automatically generates 
the proper 2-digit BCD result after a byte Add 
or Subtract operation, and eliminates the need 
for special decimal arithmetic instructions. 



Multiply (MULT) provides signed (two's com- 
plement) multiplication of two words, generat- 
ing a long-word result; or of two long-words 
generating a quadruple word result. No byte 
multiply exists because it is rarely used and, 
after sign extension, can be performed by a 
word multiply. 

Divide (DIV) provides signed (two's comple- 
ment) division of a long word by another word, 
generating a word quotient and a remainder 
word; or of one quadruple-word by a long- 
word, generating a long-word quotient and 
long- word remainder. 

Both Multiply and Divide use a conforming 
register assignment. That is, a multiply fol- 
lowed by a divide on the same registers is 
essentially a no-op. The register designation 
used in the operation description must be even 
for word operations and must be a multiple of 
four for long- word operations. 

Logical Instructions. 

Test Condition Code (TCC) performs the same 
test as a Jump instruction, but affects the least 
significant bit of a specified register instead of 
changing the PC. 

Program Control Instructions. 

Call Relative (CALR) is a shorter, faster ver- 
sion of Call, but with a limited range. 

Decrement And Jump If Non-Zero (DJNZ) is a 

one- word basic looping instruction. 

Jump Relative (JR) is a shorter, faster version 
of Jump, but with a limited range. 

Bit Manipulation Instructions. 

Test Bit, Reset Bit, Set Bit (BIT, RES, SET) are 

available in two forms: static and dynamic. For 
the static form, any bit (the position is defined 
in the immediate word of the instruction) 
located in any byte or word in any register or 
in memory can be set, reset or tested (inverted 
and routed into the Z flag). 

For the dynamic form, any bit (the position 
is defined by the content of a register that is, 
in turn, specified in the instruction) located in 
any byte or word in any register, but not in 
memory, can be set, reset or tested. 

Test And Set (TSET) is a read/modify/write 
instruction normally used to create operating 
system locks. The most significant bit of a byte 
or word in a register or in memory is routed 
into the S flag bit and the whole byte or word 
is then set to all Is. During this instruction, the 
processor does not relinquish the bus. 

Test Multi-Micro Bit and Multi-Micro 
Request/Set/Reset (MBIT, MREQ, MSET, 
MRES) are used to synchronize the access by 
multiple microprocessors to a shared resource, 
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The Instruc- such as a common memory, bus, or I/O 

tion Set device. 

(Continued) Note that the instruction MREQ (Multi- 

Microprocessor Request) h as noth ing what- 
soever in common with the MREQ (Memory 
Request) output from the Z8000 CPU. 

Rotate and Shift Instructions. 

The Z8000 CPU has a complete set of shift 
instructions that shift any combination of bytes 
or words, right or left, arithmetically or logic- 
ally, by any meaningful number of positions as 
specified either in the instruction (static) or in 
a register (dynamic). 

The CPU also has a smaller repertoire of 
rotate instructions that rotates bytes or words, 
either right or left, through carry or not, and 
by one bit or by two bits. 

The instructions Rotate Digit Left and Rotate 
Digit Right (RLDB, RRDB) rotate 4-bit BCD 
digits right or left, and are used in BCD arith- 
metic operations. 

Block Transfer and String Manipulation 
Instructions. 

Translate And Decrement/Increment (TRDB, 
TRIB) is used for code conversion, such as 
ASCII to EBCDIC. These instructions translate 
a byte string in memory by substituting one 
string by its table-lookup equivalent. TRDB 
and TRIB execute one operation and decre- 
ment the contents of the length register; thus 
they are useful as part of loop performing 
several actions on each character. 

Translate, Decrement/Increment and Repeat 
(TRDRB, TRIRB) are the same as TRDB and 



TRIB, except they repeat automatically until 
the contents of the length register become 
zero. They are therefore useful in straightfor- 
ward translation applications. 

Translate And Test, Decrement/Increment 
(TRTDB, TRTIB) tests a character according to 
the contents of the translation table. 

Translate And Test, Decrement/Increment And 
Repeat (TRTDRB, TRTIRB) scans a string of 
characters. The first character is tested and, 
depending on the contents of the translation 
table, the process stops or skips to the next 
character. Stopped characters can be used for 
further processing. 

I/O and Special I/O Instructions. 

The Z8000 CPU has two complete sets of I/O 
instructions: Standard I/O and Special I/O. 
The only difference is the status information on 
the ST0-ST3 outputs. Standard I/O instructions 
are used to communicate with Z-Bus compat- 
ible peripherals. Special I/O instructions are 
typically used for communicating with the 
Memory Management Unit. 

Both types of instructions transfer 8 or 16 
bits and use a type of 16-bit addressing 
analogous to the Z8002 memory-addressing 
scheme: For word operations, Ao is always 
zero; in byte- input operations, Ao is used 
internally by the CPU to select the appropriate 
byte; in byte-output operations, the byte is 
duplicated in the high and low bytes of the 
address/data bus, and external logic uses Ao 
to enable the appropriate output device. 
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Introduction This application note describes the hard- 

ware design implementation of a small com- 
puter using the Zilog Z8002 16-bit micro- 
processor, ROMs/EPROMs and dynamic RAMs 
plus parallel and serial I/O devices. The inter- 
face requirements of the Z8002 to memory and 
to Z80A peripherals are described and design 
alternatives are given whenever possible. This 
design is similar in structure and is software 
compatible with the Zilog Z8000 Development 



Module (part number 05-6101-01). 

The design uses a minimal number of TTL 
support devices and, whenever possible, gate 
functions have been combined into MSI cir- 
cuits. The result is a design that uses MSI TTL 
circuits in a very efficient — but sometimes non- 
obvious — way that minimizes the package 
count. Because some of the design techniques 
may not be self-explanatory, an effort has been 
made to explain them. 



General Figure 1 shows a block diagram of the 

Structure design. The Z8002 16-bit microprocessor is the 

heart of the system. This high-performance 
CPU offers a regular architecture, a powerful 
instruction set, a sophisticated interrupt struc- 
ture, and high throughput at a modest 4 MHz 
clock rate. 

For a description of the Z8002, see the 
Z8001/Z8002 CPU Product Specification 
(03-8002-01). For a detailed description of 
the Z8000 instruction set, refer to the Z8000 
PLZ/ASM Assembly Language Manual 
(03-3055-01). 

Fixed program and data information is 
stored in an array of 2K x 8 ROMs or EPROMs; 
16 16K x 1 dynamic RAMs provide 32K bytes 
of read/ write storage. Input/output is handled 
by five I/O devices. Two Z80A PIOs provide 4 
byte-wide bidirectional ports (32 lines) with 
handshake control. A Z80A SIO provides two 
fully independent full-duplex asynchronous or 
synchronous serial data communications chan- 
nels. Four counter/timers in the Z80A CTC 



relieve the processor from simple counting and 
timing tasks and generate the programmable 
baud- rates for the serial I/O channels. Eight 
switches can be interrogated and interpreted 
by the program. 

The block diagram also indicates the various 
support functions. A crystal-controlled clock 
circuit generates a Z8002 and Z80A compatible 
clock signal plus two complementary TTL 
clocks. Address buffers drive the memory and 
I/O devices; address latches demultiplex the 
time-shared Address/Data bus. 

The ROM array uses a One-of-Eight Address 
Decoder and the RAMs ar e driven b y an 
address multiplexer and a RAS/CAS 
generator. The timing for all these functions 
originates in the bus control and timing cir- 
cuit. The I/O devices are selected by an I/O 
decoder and receive Z80A equivalent control 
signals generated by the Z8002 to Z80A Con- 
trol Translator. The following sections contain 
detailed descriptions of these circuits. 
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Figure 1. Block Diagram 



Clock The Z8002 requires a continuously running 

Generation clock with a frequency between 500 kHz and 
4 MHz. Most Z8002 applications are perfor- 
mance oriented and the clock rate is therefore 
usually set close to the maximum limit of 
4 MHz. At this frequency, the specified 
requirements for clock width (minimum of 
105 ns High or Low) and clock transition times 
(maximum of 20 ns rise or fall) require careful 
attention. At 4 MHz, a 50°/o clock duty cycle is 
indirectly implied by this specification and the 



safest way to insure it is to start with a crystal 
oscillator frequency that is twice the clock 
rate, and divide it with a toggling flip-flop. 

The Z8002 clock input is not TTL compati- 
ble. It requires a High level within 400 mV of 
Vcc- A resistive pull-up can achieve this level, 
but cannot guarantee the required rise-time 
(20 ns from 0.8 to 4.0 V) when driving the 
«30 pF clock input capacitance. The strin- 
gent rise time requirements dictate the use of 
an active pull-up as shown in Figure 2. 
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Figure 2. Clock Generation 
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CPU Output The Z8002 outputs can sink 2 mA while 

Buffering maintaining TTL noise margins and can thus 

drive five LS-TTL inputs. All output delays 
are specified for a capacitive load of up to 
50 pF. They increase by approximately 
0.1 ns/pF of additional capacitive load. 



Very small systems can be built without TTL 
buffering of the CPU outputs, but most systems 

require TTL buffering of the Address/Data 

lines an d majqr_ control outputs, like AS, DS, 
MREQ and R/W. 



Bidirectional buffering of the A/D lines. The 

Address/Data lines require Bus Transceivers, 
such as the LS243 Quad Non- Inverting Bus 
Transceiver with separate Enable inputs for the 
two directions (one active High; the other 
active Low), or the LS245 Octal Non-Inverting 
Bus Transceiver with a Direction Control input 
and an active Low Enable input. 

Figure 3 shows the logic that controls four 
LS243 Quad Transceivers; Figure 4 shows the 
even simpler logic that controls two LS245 
Octal Tranceivers. 



The bus transceivers are controlled by three 
CPU control outputs as shown in the following 
truth table. 
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Figure 3. Bidirectional Address/Data Buffering Using Quad Transceivers 
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Figure 4. Bidirectional Address/Data Buffering Using Octal Transceivers 



Unidirectional Buffering of CPU Control 
Outputs. The following CPU control outputs 
may re quire unidirectional buffering: AS, DS, 
MREQ, R/W, N/S, B/W. 

The bu ffered signals must be 3-stated when 
BUSACK is Low. One LS365A or LS367A Hex 
3- State Buffer can perform this function as 
shown in Figure 5. The LS244 Octal 3- State 
Buffer buffers eight signals, but uses a 20-pin 
package. 

In a simple sy stem, suc h as the one 
described here, BUSREQ is not used, so 
BUSACK is therefore always High. In a more 
comple x system w ith direct memory access, a 
Low on BUSACK indicates that the CPU has 
relinquished the bus. If the buffered bus is 



shared, BUSACK must be used to control the 
latches and transceivers, as shown in Figures 4 
through 6. 
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Figure 5. Control Signal Buffering 
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Address The Z8002 uses a 16-bit time- shared 

Latching Address/Data bus that must be demultiplexed, 

(Demulti- that is, latched for use with standard (not 

plexing the edge- activated) memories. AS is the obvious 
A/D lines) control signal for address latching and two 

LS373 Octal Transparent Latches are the best 
choice for this function (Figure 6). Note that 



addresses are not guaranteed valid when AS 
goes Low. It is therefore not possible to use the 
falling edge of AS to clock the addresses into 
edge-triggered registers. The rising edge of 
AS may be used as a clock, but this delays 
address availability by almost 100 ns. Trans- 
parent latches are the better choice. 
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LA0-LA1S (TO SYSTEM) 

Figure 6. Address Latches 



ROM Most microprocessors use novolatile memory 

Addressing for part of their program memory. Since the 
program status information for the Z8002 is 
read after Reset from locations 0002 and 0004, 
it is natural to use the lower half of the 
addressing space for ROM or EPROM. 

This application uses 2716-type 2K x 8 
EPROMs addressed by the latched addresses 
LAi-LAn. Pairs of 2716s store the low and 
high byte of each word. Ao is ignored since 
the Z8002 always reads a full word from 
memory. LA 15 must be used as a Chip Select 
input to separate the ROM and RAM areas. 
When more than 2K words of ROM or EPROM 
are used, an LSI 38 one-of -eight decoder 
selects between the ROM and EPROM pairs. 



When driven with a 4 MHz clock, the Z8002 
reguires a read access time (address valid from 
the CPU to data reguired into the CPU) of 
400 ns. After subtracting a 27 ns propagation 
delay through the LS373 address latches and 
an 18 ns propagation delay through the LS243 
transceivers, the ROM or EPROM must have 
an access time (address in to data out) of 
better than 355 ns. Some ROMs and EPROMs 
have a longer access time and therefore 
reguire an additional wait state that relaxes the 
access time reguirement by an additional 
250 ns. Figure 8 shows a 2- input NAND gate 
that generates a Wait signal whenever LA 15 is 
Low and Q2 is High, thereby adding a wait 
state to every ROM/EPROM access. 



RAM Address Dynamic 16K x 1 RAMs such as the Z6116 
Mul tiplexing provide read/ write random-access storage. 
and RAS CAS Sixteen of these devices populate the upper 
Generation half of the addressable memory space 

(LA15 = High). Dynamic 16K RAMs use 
address multiplexing to reduce the package 
pin count, thus reguirin g only sev en ad dress 
inputs plus strobe inputs RAS and CAS. 



Address Multiplexing. Two LSI 57 Quad Two- 
Input Multiplexers route the 14 address outputs 
LA1-L A14 into the seven RAM address inputs. 
MREQ synchronized with the rising clock edge 
is a convenient signal to control this multi- 
plexer (Figure 7). 
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Figure 7. Address Multiplexer 
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RAM Address RAS a nd CA S G enera tion. The address 
Multiplexing strobes RAS and CAS must be timed carefully 
(Continued) with respect to the address informa tion an d the 
multiplexer contr ol. C onceptually, MREQ 
might be used as RAS and DS as CAS. This 
would, however, require a memory read 
access time from the falling edge of CAS of 
approximately 120 ns (parameter 33 in the 
Z8001/Z8002 Product Specification Composite 
AC Timing Diagr am, minus the 30 to 40 ns 
used by the CAS drivers and bus trans- 
ceivers). Only the fastest 16K dynamic RAMs 
(the Zilog Z6116-2, for example) meet this 
requirement. Consequently, it is more prac- 
tical to use a small amou nt of cloc ked T TL 
logic to generate earlier RAS and CAS signals 
and thus relieve the access time requirements 
so that even slow 16K RAMs (Z6116-3 and -4) 
can be us ed. F igur e 8 sh ows the circuit that 
g enera tes RAS and CAS. 

RAS is a 2-clock period (500 ns at 4 MHz) 
wide active-Low signa l starting on the falling 
clock edge when AS is Low. The address infor- 
mation is valid and stable during the specified 
hold time ( <50 ns) imm ediately after the fall- 
ing edge of RAS. RAS is generated by an 
LSI 09 edge -triggere d dual JK flip-flop, 
clocked by CLOCK (that is, of a polarity oppo- 
site to the Z8002 clock). At the end of a 
machine cycle both Ql and Q2 are High. The 



falling edge of CLOCK during AS clocks Ql 
Low. The next falling clock edge leaves Ql 
unaffected, but clocks Q2 Low. The next fall- 
ing edge clocks Ql High and leaves Q2 unaf- 
fected. The next falling clock edge clocks Q2 
High and leaves Ql High unless AS is Low, in 
which case the cycle is repeated. Ql is Low 
from the center of the first to the center of the 
third T state. Q2 is Low from the center of the 
second to the center of the fourth T state. 

The left half of th e LS I 39 Dual One-of-Four 
Decoder generates CAS by ANDing three 
signals: LA15, MUX-S, and an auxilliary signal 
active during Read or DS. 

During a read operation, CAS becomes 
active at the beginning of T 2; that i s, on the 
rising edge of CLOCK after M REQ h as gone 
Low. During a write operation, CAS is delayed 
until the beginning of DS, when output data is 
guaranteed valid. The flip-fl op str etches the 
width of DS, thus stretching CAS (during write 
operations) from 160 to 200 ns, as required by 
slower memories. 

The right h alf of the LSI 39 decoder controls 
the routing of CAS to the two memory byte 
banks. The Z8002 addresses memory as bytes, 
but usually accesses words, ignoring Ao. It 
uses Ao only when writi ng a byte, in which 
case it suppresses CAS to the byte bank that is 
not being written. 
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RAM Address Dynamic Memory Refresh. No external hard- 
Multiplexing ware is required for memory refresh. The 
(Continued) Z8002 provides automatic memory refresh if 
properly initiated through a LDCTL instruc- 
tion into the Refresh Control Register (Figure 
10). Loading a 9E00 generates a refresh oper- 
ation every 60 clock cycles (15 ^s with a 
4 MHz clock). This satisfies the worst-case 



refresh requirements of typical 16K dynamic 
RAMs. 

Figure 1 1 shows the relationship between 
the upper byte of the refresh control register 
and the refresh period expressed in clock 
cycles. (Refer to the Z8000 PLZ/ASM Assembly 
Language Programing Manual, 03-3055-01 for 
further information.) 
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Figure 11. Refresh Period in Clock Cycles 



Status The Z8002 provides encoded status informa- 

Decoding tion on four outputs (ST0-ST3), which dis- 

tinguish between three different interrupt 
acknowledge cycles; memory refresh; I/O 
reference; internal operation; data memory, 



word of an instruction fetch. Two LSI 38 
One-of-Eight Decoders can generate all the 
individual Status signals. For a simple system, 
only the first ten status codes have to be 
decoded. A single LS42 One-of-Ten Decoder is 



stack or program memory access; and the first sufficient for this purpose (Figure 12). 
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Interfacing Z-Bus compatible peripheral devices that 

Peripheral require no external logic to interface with a 
Devices Z8002 will become available in the near 

future. In the meantime, this application 
note describes the use of Z80A peripherals 
(PIO, CTC, SIO) with the Z8002. These 
peripherals require only a small number of 
additional TTL packages and a few lines of 
code to make the Z80 02 em u late the typical 
Z80A control signals IORQ, Ml, RD, and RETI. 

Four different operations are performed 
between the CPU and its peripherals: 

D CPU writing into the peripheral device. 

□ CPU reading from the peripheral device. 

D Peripheral interrupting the CPU, which 
responds with an Interrupt Acknowledge. 

D CPU issuing a Return from Interrupt (RETI) 
signal. 



The first two operations — writing to or read- 
ing from the peripheral — are fairly straight- 
forward. An LSI 38 One-of -Eight Deco der, 
enabled by the decoded Status signal IORQ, 
decodes the latched I/O address and generates 
CE signals to the individual peripheral devices 
(Figure 13). The Z8002 can use the full 16-bit 
address space for I/O, but this application uses 
only LA3-LA10. When necessary, the higher- 
order address bits can also be decoded arid 
fed into one of the Enable inputs. Notice triat 
all ports require an odd address to interface to 
the Z8000 data bus (lower byte). 

A write operation into th e enab led per- 
ipheral is performed when IORQ is Low while 
RD is High. Similarly, a read operation from 
the en abled peripheral is performed when 
IORQ is Low while RD is Low. 




TO 
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Figure 13. Z8002 to Z80A Control Translation 
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Interfacing The first four I/O devices addressed when 

Peripheral LA5 is Low are four Z80A peripheral corn- 
Devices ponents. The fifth peripheral is a set of eight 
(Continued) switches that can be read by the CPU, which 
addresses them as a peripheral device. The 
user can thus specify any one of 256 different 
conditions (for example, choosing between 16 
different baud rates for each of the two serial 
I/O channels). The sixth CE output addresses a 
phantom peripheral called RETI, which is 
activated at the end of an interrupt service 
operation. 

The interrupt operation requires some extra 
logic and software to make the Z80A per- 
ipherals compatible with the Z8002. Z80A 
peripherals request a vectored interrupt by 
pulling the VI input of the CPU Low. The CPU 
(Z80A or Z8002) samples this input at a 
specified time prior to the end of any instruc- 
tion execution. The Z8002 then acknowledges 
t he inter rupt with a specific Status code 
(VIACK). The Z80A, which has no dedicated 
Interrupt Acknowledge output, acknowledges 
interrupts by iss uing a unique combination of 
control signals: IORQ active during an Ml 
cycle (Ml normally indicates the opcode fetch 
cycle of an instruction execution). Z80A 
peripherals resolve potential conflicts between 
overlapping interrupt requests from different 
interrupting devices by means of a daisy- chain 
arrangement between the IEO outputs and the 
IEI inputs of the peripheral components. The 
highest-order peripheral has its IEI perma- 
nently tied High. For any peripheral that has 
no interrupt pending or under service, 
IEO = IEI. Any peripheral that has an interrupt 
pending or under service forces its IEO Low. 

To insure stable conditions in the daisy 
chain, all interrupt status si gnals are pre- 
vented from changing while Ml is Low. When 



IORQ is Low, the highest priority interrupt 
requestor (the one with IEI High) places its 
interrupt vector on the data bus and sets 
its internal interrupt-under-service latch. 
Figure 14 shows the Interrupt Acknowledge 
timing. 

T he circ uit shown in Figure 13 generates the 

Ml, IORQ, and RD signals required by the 
Z80A peripherals during an interrupt 
acknowledge cycle. 

Return From Interrupt. At the end of an inter- 
rupt service routine the interrupt-under-ser- 
vice latch in the Z80A peripheral that has been 
serviced must be reset. The Z80A CPU 
accomplishes this by executing a special 
2-byte instruction with the opcode sequence 
ED-4D (RETI) appearing on the data bus. All 
peripherals monitor this sequence and 
manipulate the daisy chain to reset the 
appropriate internal interrupt-under-service 
latch. The normal daisy- chain operation can 
be used to detect a pending interrupt; 
however, it cannot distinguish between an 
interrupt under service and a pending 
unacknowledged interrupt of a higher priority. 
Whenever "ED" is decoded, the daisy chain is 
modified by forcing High the IEO of any inter- 
rupt that has not yet been acknowledged. Thus 
the daisy chain identifies the device presently 
under service as the only one with an IEI High 
and an IEO Low. If the new opcode byte is 
XX 4D," the interrupt-under-service latch is reset 
(Figure 15). 

The Z8002 does not have the equivalent RETI 
instruction and must therefore simulate it with 
a combination of hardware and software. A 
software sequence at the end of every interrupt 
service routine writes two consecutive bytes 
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Figure 14. Interrupt Acknowledge Cycle 
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Figure 15. Return from Interrupt Cycle 
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(ED followed by 4D) into the phantom per- 
ipheral called RETI. The recommended soft- 
ware sequence is as follows: 



DI 

LDB 

OUTB 

LDB 

OUTB 

EI 

RET 



RL1, #%ED 
RETI, RL1 
RL1, #%4D 
RETI, RL1 



Disable Interrupts 
Load First Byte 
Output First Byte 
Load Second Byte 
Output Second Byte 
Enable Interrupts 
Return From Interrupt 



To prevent the two byte simulated RETI 
instruction from being interrupted, interrupts 
must be disabled. If NMIs can occur at any 
time, then interrupts must remain disabled 
throughout the NMI service routine. This 
allows the Z80A peripheral devices to decode 
correctly a RETI instruction. During the two 
OUTB operat ions, ea ch four clock cycles long, 
RETI is Low, VIACK is High and the Z80A 
control signals Ml and RD are Low. 



Driving Z80A Peripherals. The Z80A PIO, 
CTC and SIO are directly connected to the 
appropriate lines, as follows. The bidirectional 
AD0-AD7 buffers are connected to the D0-D7 
data inputs/outputs on the peripherals. 

The address bits LA] and LA2 are used as 
Port Select (A/B) and Control Data select 
(C/D) on the PIO and SIO, and as Channel 
Select (CSo, CSi) on the CTC. 

The Interrupt outputs of all peripherals are 
interconnected (pulled up with a 4.7kfl resistor 
to Vcc an d connected to the VI input of the 
Z8002). The IEI-IEO interrupt daisy chain of 
the Z80A peripheral devices must be con- 
nected appropriately to establish the desired 
hierarchy of interrupt priorities. 

The Z80A PIO requires a Ml to enable the 
peripheral circuit's internal interrupts. This 
can easily be accomplished by writing a 
dummy byte (00H) to the RETI port after PIO 
interrupts have been enabled. 



Reset The Z8000 Reset input requires a minimum 

High level of 2.4 V. While TTL High levels are 
guaranteed to be at least 2.4 V, this does not 
leave margin for noise immunity. If an open 
collector buffer (such as a 7407) is available, 
an output pullup resistor to + 5 V will provide 



more than adequate margin for noise immun- 
ity. If an open collector gate is not readily 
available, a standard TTL gate may be used 
with an output pullup resistor. In this case, the 
value of the pullup resistor should not be less 
than 300 Q. 



Conclusion This Application Note demonstrates that a 

small, but powerful computer can be built 
around the Z8002 16-bit microprocessor using 
very few standard TTL support packages. It 



also shows how the readily-available Z80A 
peripheral circuits interface easily to the 
Z8002, taking advantage of the similarity in 
the Z80A and Z8000 interrupt structures. 
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Introduction The declining cost of memory, coupled with 

the increasing power of microprocessors, has 
accelerated the trend in microcomputer 
systems to the use of high-level languages, 
sophisticated operating systems, complex pro- 
grams and large data bases. The Z8001 micro- 
processor supports these advances by offering 
multiple 8M byte address spaces as well as a 
rich and powerful instruction set. The Z8010 
Memory Management Unit (MMU) supports the 
Z8001 processor in the efficient and flexible 
use of its large address space. 

Support for managing a large memory can 
take many forms: 

■ Providing a logical structure to the memory 
space that is largely independent of the 
actual physical location of the data 

■ Protecting the user from inadvertent 
mistakes such as attempting to execute data 



■ Preventing one user from unauthorized 
access to memory resources or data 

■ Protecting the operating system from unex- 
pected access by the users. 

The Z8010 provides all these features plus 
additional features that permit a variety of 
system hardware configurations and system 
designs. 

This paper examines the various uses of 
memory management in computer systems and 
how memory management techniques gen- 
erally meet these requirements. The major 
features of the Z8010 MMU illustrate how 
memory management functions can be sup- 
ported by hardware. A few examples demon- 
strate how this LSI circuit can be used to 
configure several different memory man- 
agement systems. 



Motivations The primary memory of a computer is one of 

for Memory its major resources. As such, the management 
Management of this resource becomes a major concern as 
demands on it increase. These demands can 
arise from different sources, three of which are 
of interest in the present context. The first 
stems from multiple users (or multiple tasks 
within a dedicated application) contending for 
a limited amount of physical memory. The 
second comes from the desire to increase the 
integrity of the system by limiting access to 
various portions of the memory. The final 
source arises from issues surrounding the 
development of large, complex programs or 
systems. Each of these three sources involves a 
multifaceted group of related issues. 

When multiple tasks constitute a given 
system (for example, multiple users of a system 
or multiple sub-tasks of a dedicated applica- 
tion), the possibility exists that not all tasks 
may be m primary memory at the same time. 
(A task is the action of executing a program on 
its data; a task may be as simple as a single 



procedure or as complex as a set of related 
routines.) If the population of memory- resident 
tasks can vary over time, a useful feature of a 
system would be the ability for a task to recide 
anywhere in memory, and perhaps in several 
different locations during its lifetime. Such 
tasks are called relocatable, and a system in 
which all tasks are relocatable generally offers 
greater flexibility in responding to changing 
system environments than a system in which 
each task must reside in a fixed location. 
A second issue that arises in multi-task 
environments is that of sharing. Separate tasks 
may execute the same program on different 
data, and may therefore share common code. 
For example, several users compiling FOR- 
TRAN programs may wish to share the com- 
piler rather than each user having a separate 
copy in memory. Alternatively, several tasks 
may wish to execute different programs using 
the same data as input, and it may be possible 
for these tasks to access the same copy of the 
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Motivations input. For example, a user may wish to print a 
for Memory PASCAL program while it is being compiled; 
Management the print process and the compiler process 
(Continued) could access the same copy of the text file. 

A third issue in multi-task systems is protect- 
ing one task from unwanted interactions with 
another. The classic example of unwanted 
interaction is one user's unauthorized reading 
of another user's data. Prohibiting all such 
interactions conflicts with the goal of sharing 
and so this issue is usually one of selectively 
prohibiting certain types of interactions. The 
issue of protecting memory resources from 
unauthorized access is usually included in the 
larger set of issues relating to system integrity. 

System integrity takes many forms in addi- 
tion to protecting a task's data from unwanted 
access. Another aspect is preventing user tasks 
from performing operating system functions 
and thereby interrupting the orderly dispatch 
of these tasks. For example, most large systems 
prevent a user task from directly initiating I/O 
operations because this can disrupt the correct 
functioning of the system. 

Another aspect of separating users from 
system functions relates to separating system 
I/O transfers from user tasks, especially with 
respect to error conditions. For example, an 
error during a direct memory access, say to a 
nonexistant memory location, should not cause 
an error in the program that is currently 
executing. 

A final example of increasing the system 
integrity is protecting a user task from itself. 
Obvious errors, such as trying to execute data 
or overflowing an area set aside for a stack, 
can be detected while a program is executing 
and handled appropriately, provided the 
system is given sufficient information. 

The notion of protecting an executing task 
from performing certain types of actions known 
to be erroneous introduces a third general 
motivation for memory management, namely 
support for the design and correct implementa- 
tion of large, complex programs and systems. 



Protecting a task from itself obviously helps in 
debugging a large program, but there are 
other system features that can aid in develop- 
ing complex systems. Modern methodology for 
developing large systems dictates partitioning 
a task into a number of small, simple, self- 
contained sub-tasks with well defined inter- 
faces. Each sub-task generally interacts with 
only a few other sub-tasks and this communica- 
tion is carefully controlled. This methodology 
promotes a systems design that can be readily 
modified, but it also tends to promote the crea- 
tion of a large number of nearly independent 
sub-tasks and many data structures accessible 
to only one or a few of these sub- tasks. 
Because modern systems are increasingly 
driven to support many interacting tasks, 
possibly written and compiled separately, they 
must also enforce some communication pro- 
tocol without sacrificing efficient operation. 
Modern memory management systems can 
offer effective tools for implementing large 
systems designed using this meihouoloyy. 
In summary, the major goals of memory 
management systems are to: 

■ Provide flexible and efficient allocation of 
memory resources during the execution of 
tasks 

■ Support multiple, independent tasks that 
can share access to common resources 

■ Provide protection from unauthorized or 
unintentional access to data or other 
memory resources 

■ Detect obviously incorrect use of memory by 
an executing task 

■ Separate users from system functions. 

Most of today's memory management systems 
support these functions to some degree. The 
extent of this support is largely a question of 
resources to be devoted to these functions and 
the understood demands of the intended 
applications for these systems. 



The Funda- Memory management has two functions: 

mentals of the allocation and the protection of memory. 
Memory Dynamic relocation of tasks during their 

Management execution is accomplished by an address 
translation mechanism. The restriction of 
memory access is accomplished by memory 
attribute checking. Both operations occur with 
each memory request during the execution of a 
program and both are transparent to the user. 

Address translation simply means treating 
the memory addresses generated by the pro- 
gram as logical addresses to be interpreted or 
translated into actual physical memory loca- 
tions before dispatching the memory access 
requests to the memory unit. Memory attribute 
checking means that each area of memory has 
associated with it information as to who can 



access it and what types of access can be made 
by each task. Each memory reference is 
checked to insure that the task has the right to 
access that location in the given fashion (for 
example, to read the contents of the location or 
to write data to that location). 

Instead of a linear address space, more 
elaborate memory management systems have a 
hierarchical structure in which the memory 
consists of a collection of memory areas, called 
segments. Access to this structured memory 
requires the specification of a segment and an 
offset within that segment. Thus, instead of 
specifying memory location 1050 in a linear 
address space, a task specifices memory loca- 
tion 5 in segment number 23, for example. 
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The Funda- Generally, segments can be of variable size, 

mentals of within limits, and a user can specify the size of 

Memory each segment to be used. Thus one user may 

Management have two segments of two thousand and ten 
(Continued) thousand words for his FORTRAN program and 
data, respectively, while another user might 
have three segments of three thousand, six 
thousand and two thousand words for her 
PASCAL program, data, and run-time stack. If 
the first user called his data segment number 
5, then the first word in his data set would be 
accessed by the logical address (5,0) indicat- 
ing segment 5, offset 0. The memory man- 
agement system translates this symbolic name 
into the correct physical memory address. 

Figure 1 gives a conceptual realization of 
these two users' logical program spaces. The 
first user, User A, has his program segment 
called "Segment 6" and his data segment 
called "Segment 5." The second user, User B, 
has her program segment called "Segment 5," 
her data segment called "Segment 12" and her 
stack segment called "Segment 2." Notice that 
both users have named one of their segments 
"Segment 5," but they refer to different enti- 
ties. This causes no problem since the system 
keeps the two memory areas separate. The 
situation is analogous to both users having an 
integer variable called "I" in their programs: 
The system realizes that these are two separate 
variables stored in different memory locations. 
User A's data segment, "Segment 5," is ten 
thousand words. If he references word 10,050 
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of Segment 5 he gets an error message from 
the system indicating that he has exceeded the 
allocation limit for Segment 5. Note that he 
does not access word 50 of Segment 6. That is, 
segments are logically distinct and unordered. 
A reference to one segment cannot inadvert- 
ently result in access to another segment. 
Thus, in this example, User A is prevented 
from accidentally (or deliberately) accessing 
his program as though it were part of his data 
segment. 

Figure 2 illustrates one way that these 
segments could be arranged in the physical 
memory. The dotted lines indicate the 
memory-mapping function from the logical 
address space of the user to the physi- 
cal memory locations allocated to him. 
The figure also indicates the access attri- 
butes associated with each user's segments. 
For example, program segments are "exe- 
cute only" and data segments are "read/ 
write." Thus a user is prevented from exe- 
cuting a data segment or writing into a 
code segment. 
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The Funda- Figure 3 illustrates what happens when 

mentals of both users have access to the same data 

Memory set in primary memory, say the results of a 

Management questionnaire that both intend to analyze. 
(Continued) Each user has a logical name associated 

with that data set to specify the segment in 
which the data set is to reside. Note that the 
two users have chosen to put the data set in 
different segments of their personal address 
spaces. The system-mapping function trans- 
lates these different segment names to the 
same physical memory locations. Thus User 
A's access to address (2, 17) references the 
same physical memory location as User B's 
access to address (7, 17). In the figure, note 
that two of B's segments have been moved in 
physical memory to create a space large 
enough to hold the questionnaire data. 

Another topic in memory management that is 
supported by Z8001-Z8010 architecture but 
requires additional support hardware is 
demand swapping, or segmented virtual 
memory, which means that the logical memory 
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Figure 3. Two Users Sharing a Common Segment 



area may not actually reside in physical 
memory until a task actually tries to access it. 
At the time an access is made to a segment 
missing from physical memory, the instruction 
execution is held in abeyance until the logical 
memory can be brought into the physical 
memory and then the instruction is allowed to 
proceed with the memory access. The address 
translation is performed, access protection is 
checked and the instruction proceeds as if the 
logical memory area had been in the physical 
memory at the beginning of the instruction. 
The instructions in the Z8001 must run to com- 
pletion before the CPU can perform any 
action, such as responding to a missing seg- 
ment trap. But with the conjunction of hard- 
ware and software to simulate the above func- 
tions, a segmented virtual memory scheme can 
be implemented. 

A final topic in memory management is 
paging, which is another method for partition- 
ing a user address space and mapping it onto 
the physical memory. Paging is most effective 
when demand swapping can be supported. 
Essentially, paging divides the logical memory 
into fixed-size blocks, called pages. Like 
segments, the individual pages can be located 
anywhere in the physical memory and a 
translation mechanism maps logical addresses 
to physical memory locations. There are two 
differences between paging and segmenting a 
logical memory. First, pages are of fixed size 
whereas segments are of various sizes. Second, 
under paging, the logical memory is still 
linear, that is, a task accesses memory using a 
single number, rather than a pair as in 
segmentation. The major advantage of paging 
is in treating memory as blocks of fixed sizes, 
which simplifies allocating memory to users 
and deciding where to place the logical pages 
in physical memory. The major disadvantage 
of paging is in assigning different protection 
attributes to different areas in a user address 
space because a paged memory appears 
homogeneous to the user and the operating 
system. Paging can be combined with segmen- 
tation to produce a memory management 
system with the advantages of both paging and 
segmentation. The implementation of paging 
for the Z8001 requires additional support hard- 
ware and may be implemented independent of 
the Z8010. 

Before proceeding to the mechanism of 
memory management, it is instructive to review 
how a segmented address translation 
mechanism with protection attributes achieves 
the five major goals of memory management 
outlined in the previous section. The first goal 
permits dynamic allocation of memory during 
the execution of tasks; that is, a task could be 
located anywhere in memory and even moved 
about when its execution is suspended. The 
address translation mechanism provides this 
flexibility because the task deals exclusively 
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The Funda- with logical addresses and hence is mdepen- 
mentals of dent of the addresses of the physical memory 

Memory locations it accesses. Moving the task to dif- 

Management ferent physical memory locations requires that 
(Continued) the address mapping function be changed to 
reflect the change in memory location, but the 
task's code need not be modified. Of course, 
this flexibility does incur the price of manag- 
ing the various system tables required to 
implement memory management. 

The second goal supports sharing of com- 
mon memory areas by different tasks. This is 
accomplished by mapping different logical 
areas in different tasks to the same physical 
memory locations. 

The third provides protection against certain 
types of memory accesses. This is accomp- 
lished by associating accessing attributes with 
each logical segment and checking the type of 
access to see if each access is permitted. 

The fourth goal detects obvious execution 
errors related to memory accessing. This can 
be accomplished by checking each access to a 
segment to see whether the address falls within 
the allocated physical memory for that seg- 
ment. It could also include affixing a 
read/write attribute to data to prevent a task 
from trying to execute a data segment, and 
affixing an execute-only attribute to code 
segments to prevent a task from trying to read 
or write data to this segment. Additionally, if a 
segment is used for a stack, the system could 
issue a warning to a task when the stack 
approaches the allocated limit of the segment. 
The task could then request more memory for 
the stack before the stack overflows and 
creates a fatal error. 

The final goal listed for memory manage- 



ment systems separates user functions from 
system functions. For processors that dis- 
tinguish between System mode and User mode 
of operation, this goal can be accomp- 
lished by associating a system-only attribute 
with system segments so users cannot directly 
access system tables and tasks. 

As a final point, it should be noted how 
segmentation can be used to support the 
development and execution of large, complex 
programs and systems. The concept of segmen- 
tation corresponds to the concept of partition- 
ing a large system into procedures and data 
structures where each procedure and data 
structure can be associated with a separate 
segment. A task can then invoke a procedure 
or sub-task or access a data structure by refer- 
ring to its logical segment name. Access to 
these objects can be individually restricted by 
using the protection- checking mechanism of 
the memory management system. 

As a specific example of how segmentation 
could be used in the design of a large system, 
consider a multi-user interactive BASIC system 
with a large data base shared by all users. 
Such a system could be designed with 
segments through 15 reserved for system 
use, segments 16 through 31 reserved for the 
BASIC interpreter and its internal tables, 
segments 32 through 63 allocated to user tasks 
and segments 64 through 127 reserved for por- 
tions of the data base when they are m primary 
memory being accessed by users. For this 
system, segments through 31 would probably 
always be m memory; the other segments 
would be assigned as needed and the memory 
they require allocated dynamically. 



The Mechan- Essentially there are four issues m lmple- 
ics of Memory mentmg a memory management system: how 
Management addresses are specified, how these addresses 
are translated, what attributes are checked for 
each access, and how the protection mech- 
anism is implemented. Some of the major alter- 
natives m each of these issues are briefly 
discussed here, primarily from the point of 
view of a segmented memory. 

Two approaches have traditionally been 
taken for specifying addresses in a segmented 
memory. For simplicity, only addresses in 
instructions are discussed. The first way 
puts all the addressing information in the 
instruction itself. That is, each memory address 
m an instruction contains both the segment 
name and the offset within the segment. The 
alternative sets aside special registers that con- 
tain some of this information, for example the 
segment name or the address in physical mem- 
ory where the segment resides. 

The advantage of the latter approach lies in 
the fact that fewer bits are needed in an 
instruction to specify addresses. Thus pro- 
grams may be shorter. Also, because there is 



reduced traffic between the memory and the 
processor for fetching shorter instructions, a 
program may execute faster. 

On the other hand, these special registers 
must be manipulated to access more segments 
than there are registers, and this manipulation 
adds to the number of instructions, the pro- 
gram size and the execution time. In practice, 
these can destroy the advantages described 
above. If the special registers contain physical 
memory locations, then these must be pro- 
tected from user access to maintain the integ- 
rity of the system, and changing segments 
requires system calls which can be time con- 
suming if too few registers are supplied. The 
Z8001 architecture specifies the complete 
logical address in the instruction. 

Address translation is performed by adding 
the logical segment offset to the memory loca- 
tion where the segment begins. Thus, when an 
address of the form (a, b) is presented to the 
translation mechanism, the segment name u a" 
is used to determine where segment "a" 
resides in memory. Assume that it resides in 
locations 10000 to 25000. Then the actual 
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memory location of (a, b) is memory location 
10000 + b. The major option in implementing 
this type of address translation is in determin- 
ing the segment location in physical memory . 
When special registers have been set aside to 
contain the starting location of the segment 
instead of putting all address information in 
the instruction, the addressing mechanism is 
similar to using the segment register as an 
index register or a base register. 

When logical addresses are either complete- 
ly specified in the instruction or when the 
special register contains the symbolic segment 
name, a table must be used to translate the 
logical segment name into a physical memory 
location. The table may have an associative 
capability, that is, the segment name is 
presented to the table and the device returns 
the physical memory location where the seg- 
ment begins. Alternatively, the table could 
have one entry for every possible segment 
name. The Z8010 implementation of the 
address translation table sets aside a specific 
table entry for each logical segment name. 

A number of attributes can be associated 
with a segment and checked during each 
access. One of these is the allocated length of 
the segment, and each access is checked to 
see if it falls within the bounds of the segment. 
The Z8010 provides limit checking. 

Another type of attribute deals with owner- 
ship or class of ownership: tasks are grouped 
into classes and only those in certain classes 
are permitted access. The simplest example is 
the system versus user classification, where 
tasks are either one or the other and this deter- 
mines whether or not any type of access can 
be made to the segment. The Z8010 has this 
feature — users are prevented from accessing 
system segments. 

Other types of attributes that can be 
associated with a segment involve modes of 
accessing, for example read only, read/write 
or execute only. For these attributes, the pro- 
cessor must indicate the type of access to be 
made, be it code fetch, read from memory, 
write to memory, etc. The Z8001 indicates 
when it is fetching code, reading or writing 
data, or performing stack operations, and thus 
the Z8010 can offer protection for these opera- 



tions. The other issue with respect to attributes 
is whether they are permissive or prohibitive. 
That is, whether the attribute is in the form of 
"write to this segment is permitted" or of the 
form u write to this segment is prohibited." The 
Z8010 adopts the approach of specifying attri- 
butes that prohibit certain types of accessing. 

The final issue in the mechanics of memory 
management systems is the implementation of 
the protection attributes. These may be 
associated either with the logical address 
space or with the physical memory itself. The 
IBM 360 series, for example, places the 
memory protection information with the 
physical memory itself. Thus the processor 
generates a memory address and the memory 
module checks to see if the access is permit- 
ted. The mam difficulty with this approach is 
in the lack of flexibility, because protection is 
associated with fixed memory partitions. Also, 
sharing memory is cumbersome because each 
user is given a protection ke v to match tho 
memory key; thus both users must have the 
same access key or a universal access key. 
Associating access attributes with the logical 
segment permits a versatile memory manage- 
ment scheme because different users can 
access the same segment and have different 
access attributes associated with their access- 
ing. The Z8010 implements access attributes 
using the segment mapping information. 

Other information associated with each seg- 
ment does not pertain to the protection 
mechanism but can be of use to the memory 
management system. This information gener- 
ally relates to the history of the segment; for 
example, whether a segment has been 
modified while resident in primary memory. If 
it has not been modified and the system 
requires the memory for another segment, the 
memory can be freed immediately; otherwise, 
the updated version of the segment must be 
stored in secondary memory and the primary 
memory is not available until the segment has 
been saved. Although not strictly necessary, 
such information can improve the performance 
of the memory management system. The Z8010 
collects information on segment usage, and 
this information can be used to enhance per- 
formance of systems that use this device. 



The Z8010 The Z8001 CPU generates segmented 

Memory addresses consisting of a 7- bit segment number 

Management and a 16-bit segment offset address. In addi- 
Unit tion, the CPU generates status signals indi- 

cating its current mode of operation (such as 
Instruction Fetch, Data Memory Reference, 
Stack Memory Reference, and Internal Opera- 
tion), whether it is performing a Read or a 
Write Memory Reference and whether it is in 
Normal (User) or System Mode. The Z8010 
Memory Management Unit uses this informa- 
tion to perform its memory management func- 
tions. This section describes the Z8010 MMU in 



some detail, beginning with the translation 
procedure and continuing with a description of 
the internal registers of the chip. The section 
concludes with a description of the system 
commands that alter the contents of these 
registers. 

The Z8010 MMU has three functional states. 
The first is the memory management state: 
when a logical address is presented to the unit, 
the MMU checks the access to insure its valid- 
ity and translates the logical address to a 
physical memory location. The second state is 
a command state: when a special I/O instruc- 
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The Z8010 tion is issued to the MMU, such as reading or 

Memory writing one of its internal registers, the MMU 

Management responds to the command as appropriate. The 
Unit third state is a quiescent state: when the CPU 

(Continued) issues an I/O instruction or a refresh cycle, the 
MMU address lines remain 3-stated. 

The inputs to the MMU are the Address/Data 
lines (A/D lines), Segment Number lines, Bus 
Status and Timing Lines, and special control 
lines for chip selection and DMA. The outputs 
from the MMU are Address lines, a Segment 
Trap line and a Suppress line (Figure 4). Dur- 
ing address translation and access protection, 
logical addresses are presented to the MMU on 
the Segment Number and Address/Data lines; 
the MMU puts the translated physical memory 
location on its Address lines and, if appro- 
priate, activates the Segment Trap and/or Sup- 
press lines. 

Segment Trap is a special type of syn- 
chronous interrupt for the Z8001 CPU; Sup- 
press aborts the memory access. In the com- 
mand state, the MMU receives commands on 
the A/D lines; data to be read from or written 
into the MMU is also placed on the A/D lines. 
The MMU selects which of the three states it 
will be in according to the status information 
on the Bus Status lines during the initial clock 
cycle of an instruction or DMA cycle. The 
MMU performs address translation during a 
memory reference for either a regular instruc- 
tion or a DMA request. Only I/O instructions 
(either regular or special), memory refresh and 
reserved bus status states cause the MMU to 
cease performing memory address translations 
and enter another state. 

The MMU uses the segment number to 
access an internal table of segment descriptor 
registers, each register containing the starting 
memory location of the segment (called the 
base address), the segment's limit (used to 
determine the range of legal address offsets) 
and the types of accesses permitted to that 
segment. 

Physical memory for segments is allocated in 
blocks of 256 bytes. The eight least significant 
bits of the base address are all zero and are 
not stored in the Segment Descriptor Register. 
Also, since the eight low-order bits of the seg- 
ment base are always zero, the eight low-order 
bits of the segment offset need not participate 
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Figure 4. Z8010 MMU Pin Functions 

in the addition of the base address to the off- 
set. Rather, they can be juxtaposed to the 
result of adding the high-order byte of the off- 
set to the most significant 16 bits of the base 
address. 

This process is illustrated in Figure 5. Note 
that the low-order eight bits of the offset are 
not used by the MMU. Figure 6 goes through 
an example of mapping the logical address 
(5, 1528) to a physical memory location when 
segment 5 begins at location 231100. 

Figure 6a illustrates the full addition to be 
performed during address translation. The seg- 
ment number 5 selects Segment Descriptor 
Register 5 in the MMU. The base address field 
in this register contains 2311 which corre- 
sponds to a base address of 231100. The offset, 
1528, is then added to 231100 to produce the 
physical memory location 232628. Figure 6b 
represents the same logical procedure, but 
illustrates the actual operation of the MMU. 
Again segment number 5 is used to select the 
base address. However, only the high-order 
byte of the offset is added to the contents of the 
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The Z8010 MMU base-address field: 15 is added to 231 1 

Memory to produce the most significant 16 bits of the 

Management physical memory location. The low- order byte 
Unit of the physical location is the same as the low- 

( Continued) order byte of the offset. 

The results of the two processes illustrated in 
figures 6a and 6b are the same, but in 6a a 
24-bit addition is implied whereas in 6b only a 
16-bit addition is needed. Also, the low-order 
eight bits of the offset are not needed by the 
MMU and this reduces the number of pins 
required by the MMU package. 

The MMU checks memory references for two 
types of trap conditions. The first type is an 
access violation. This occurs when a memory 
reference is performed in a mode that is not 
allowed by the read-only, execute-only, CPU- 
inhibit or system-only attribute of a segment. A 
memory reference outside the allocated 
memory for the segment also constitutes an 
access violation. 

The second type is a write warning. This 
occurs when a write is made to the last 256 
bytes of a special type of segment (indicated 
by a special attribute flag called the Direction 
And Warning Flag). These segments are 
typically used for stacks and are therefore 
logically organized so that successive writes 
(or stack pushes) access lower-numbered 
memory locations. By generating a segment 
trap request when a write is performed into the 
lowest-numbered 256 bytes of the memory 
allocated for these segments, the MMU is 
signaling that a stack is in danger of overflow- 
ing. The operating system in servicing this 
trap can increase the memory allocated for the 
segment and avoid a fatal stack overflow 
condition. 

The MMU generates two control signals that 
can be used by the system to perform memory 
management functions. Segment Trap Request 
is generated upon the first detected occur- 
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Figure 6. Two Methods of Address Translation 

ranee of a violation or write warning. Once 
asserted, this signal remains set until a trap 
acknowledge signal is received. Only when the 
Fatal Flag, a special MMU control flag, is set 
will a detected violation not cause a segment 
trap request. This flag is set only when a 
second violation is detected while a previous 
trap is being processed and thus indicates that 
the system software is in error. 

The other control signal generated by the 
MMU is Suppress. Once a violation has been 
detected, this signal is asserted on that and 
every succeeding memory reference for the 
remainder of the instruction. In particular, I/O 
and Special I/O instructions are checked for 
memory access violations, and once a memory 
access violation is detected, subsequent 
memory accesses cause Suppress signals to be 
generated. I/O addresses, of course, bypass 
the MMU and are neither translated nor 
checked. Intervening DMA cycles and memory 
refresh cycles are exceptions to this rule. Dur- 
ing such cycles Suppress is not asserted unless 
a violation is detected during that cycle. Only 
DMA can generate a violation; refresh can 
never cause a violation. Suppress can be used 
by the memory system to inhibit writes, thus 
protecting the memory from illegal alterations. 



MMU There are three groups of registers in the 

Internal MMU: Segment Descriptor Registers, Control 

Registers Registers and Status Registers. The Segment 

Descriptor Registers contain all the information 
relating to the address translation and access 
protection of a particular segment. The Con- 



trol Registers contain information used to con- 
trol the various functions of the MMU, includ- 
ing how to interpret various signals generated 
by the CPU. The Status Registers contain all 
the information the MMU generates when it 
detects an access violation. 



Segment Because there ,are 64 Segment Descriptor 

Descriptor Registers in the MMU, two MMUs are required 

Registers to handle all 128 segments that the Z8001 can 

manipulate directly. An MMU is programmed 
to handle either segments through 63 or 
segments 64 through 127; the particular set of 
64 segments in an MMU can be changed using 
special operating system commands. Each Seg- 
ment Descriptor contains three fields, a 16-bit 
Base Field, an 8-bit Limit Field and an 8-bit 
Attribute Field (Figure 7). The segment 
number of a logical address determines which 



segment descriptors are used in address 
translation. 

The Base Field specifies the starting location 
in memory of the segment. 

The Limit Field specifies the segment size in 
blocks of 256 bytes. The address offset is com- 
pared against the segment limit and a size 
violation occurs if the offset falls outside the 
segment boundaries. A write warning occurs if 
the destination is in the last block of a segment 
being used as a stack. 
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The Attribute Field contains eight flags. Five 
flags protect the segment against certain types 
of access, one indicates a special orientation of 
the segment, and two indicate the types of 
accesses that have been made to the segment. 
The following brief description explains how 
these flags are used. 

The Read-Only Flag (RD) indicates that the 
only accesses to this segment are reads. Writes 
are prohibited when this flag is set. Thus this 
flag is a write-inhibit flag; in particular, code 
can be executed from a read-only segment. 
This flag is useful in protecting data from 
being written by unauthorized users. For 
example, if one user wants to give another 
access to a document that he has created, but 
does not want this user to be able to modify it, 
the system can set the Read-Only Flag when it 
copies the file into the user's address space. If 
the data is already in memory (in a read-only 
mode), then this same memory area can be 
made accessible to that user without another 
copy of the document being required. 

The System-Only Flag (SYS) indicates that 
only accesses made in System Mode are to be 
permitted. When this flag is set, accesses in 
the Normal Mode are prohibited. This attribute 
is useful in protecting system tables and tasks 
from being accessed by users. For example, 
system I/O routines can be left in the memory 
with this flag set and a user is unable to call 
them directly. This feature is useful if a system 
is designed so that users are given certain seg- 
ment names and other segment names are 
reserved for system use. This flag prevents 
users from accessing system segments, even 
though they can generate the logical 
addresses. 

The CPU-Inhibit Flag (CPUI) indicates that 
the segment is not to be referenced by the 
CPU. When this flag is set, CPU access to this 
segment is prohibited, but DMA channels can 
access the segment. This flag is useful in 
preventing a program from accessing a seg- 
ment whose data resides on secondary storage 
and has not been brought into primary 
memory. For example, a user may request the 
operating system to read a file from disk into 
segment number 19; if the operating system 
returns control to the user before the file has 
been read, this flag should be set in Segment 
Descriptor Register 19. 

The Execute-Only Flag (EXC) indicates that 
the segment is to be referenced only during 
the instruction fetch cycle of the processor. 
When this flag is set, access to the segment 
during any other cycle of an instruction, for 
example during the memory request cycle, is 



prohibited. This flag is useful in preventing a 
program from making a copy of a proprietary 
program. For example, if this flag is set for a 
segment containing code that a user can 
access, that code is protected from being read 
and hence from being copied. 

The DMA-Inhibit Flag (DMAI) indicates that 
the segment is not to be referenced by a DMA 
Channel. When this flag is set, only the CPU 
has access to the segment. This flag is useful 
in preventing a DMA device from modifying a 
segment being used by an executing task. For 
example, segments with valid data should have 
this flag set to protect them from modification 
by a DMA device. O 

The Direction And Warning Flag (DIRW) & 

indicates that memory accesses are to be 
monitored and certain accesses are to be 
signaled, although allowed to proceed. When 
this flag is set, any write to the lowest 256 
bytes of the segment generates a write warn- 
ing. This flag is useful for segments that are 
used as stacks since the Z8001 has special 
stack instructions to manipulate stacks that 
grow toward lower memory locations. Thus a 
write warning for a stack indicates that the 
stack may soon overflow its allotted memory 
space and that more physical memory should 
be obtained. For example, if a segment serves 
as a run-time stack for a block-structured pro- 
gramming language such as PASCAL, memory 
can be allocated to this segment only as a pro- 
gram requires during its execution. The alter- 
native in a fixed allocation environment is to 
allocate as much memory for the stack as the 
system expects the program to need, whether 
or not it is actually used by the program. 

The Changed Flag (CHG) indicates that a 
write has occurred to this segment. This flag is 
set automatically whenever a program or DMA 
device writes into the segment. This flag is 
useful in indicating which segments have been 
modified in the case where the segment must 
be written to a secondary storage device. 
Segments that have not been updated need not 
be copied back to disk if a copy already exists. 
For example, when a user task is suspended in 
a multiple-user environment and his task is to 
be swapped out of memory temporarily to 
make room for another task, only those 
segments that have been changed need to be 
updated on the disk. 

The Relerenced Flag (REF) indicates that a 
memory access has been made to a segment. 
This flag is set automaticaly whenever a pro- 
gram or DMA device accesses the segment. 
This flag is useful in indicating which segments 
are active in the case that a segment must be 
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selected to be swapped out of primary memory 
to make room for another task. For example, 
seldom-used operating- system tasks that usual- 
ly reside in primary memory may be swapped 



out to make room for users with large memory 
requirements. This flag is a way of ascertaining 
which segments contain seldom used tasks. 



Control Three user-accessible 8-bit registers in the 

Registers MMU control the functioning of the MMU 

(Figure 8). The Mode Register provides a 
sophisticated method for selectively enabling 
MMUs in a multiple-MMU configuration. The 
Segment Address Register (SAR) selects a par- 
ticular segment descriptor to be accessed by a 
system routine when it is changing the 
organization of primary memory. The Descrip- 
tor Selection Counter Register selects the par- 
ticular byte in the Segment Descriptor Register 
that is accessed. 

Two flags in the Mode Register govern the 
functioning of the MMU. The Master Enable 
Flag (MSEN) indicates whether the device will 
perform address translation. When this flag is 
set addresses translated b v the MMU are 
placed on its Address lines; when this flag is 
clear, the Address lines are 3-stated. Thus, 
once this flag is reset, no memory request can 
pass through the MMU. In a single-MMU con- 
figuration, MSEN set to zero requires that the 
CPU must have access to a special memory, 
since it will not be able to fetch an instruction 
from the primary memory. This flag can be set 
during hardware reset (this is discussed later). 

The second flag in the mode register that 
governs the functioning of the MMU is the 
Translate Flag (TRNS). This flag indicates 
whether the MMU is to translate the addresses 
presented to it. When the flag is set, the MMU 
translates logical addresses to physical memory 
locations and checks to see if a violation will 
occur on that access. When the flag is clear, 
addresses presented to the MMU are passed to 
the output Address lines without change, and 
no protection checking is done. 

When multiple-MMUs are used in a memory- 
management system, some mechanism must be 
present to select those devices that are to be 
active during the memory translation process. 
More specifically, if two MMUs are employed 
so that all 128 segments can be used at random 
by an executing process, then some way must 
exist for each of the MMUs to know which 64 
Segment Descriptors are located in its Segment 
Descriptor Registers. The Upper Range Select 
Flag (URS) indicates which set of 64 descrip- 
tors is stored in the MMU. When the flag is 
set, the MMU contains descriptors 64 through 
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127; when the flag is reset, the MMU contains 
descriptors through 63. 

When multiple-MMU devices keep separate 
tables for system descriptors and user descrip- 
tors, the Multiple Segment Table Flag (MST) 
and the Normal Mode Select Flag (NMS) in the 
Mode Register distinguish which MMUs con- 
tain system descriptors and which contain user 
descriptors. When the MST flag is set, multiple 
tables are present m the configuration, and 
each MMU is dedicated to one of the tables. In 
this case the MMU translates addresses only 
when the N/S signal matches the NMS flag. 
Thus, if there are two tables in the memory 
management system (one for the system and 
one for users), the NMS flag is set in those 
MMUs containing the users' segment descrip- 
tors, and is not set in the remaining MMUs. All 
MMUs in the system have the MST flag set to 
indicate more than one table in the system. 

The final piece of control information in the 
Mode Register is a 3-bit Identification Field 
(ID) that indicates a logical name for the 
MMU. When a segment trap is acknowledged 
by the CPU, the MMU uses this field to select 
one of the A/D lines; each enabled MMU 
should select a different line. If an MMU 
requested a segment trap, it outputs a 1 on its 
assigned A/D line; otherwise it outputs a 0. 
Since the ID field is three bits, up to eight 
MMUs can be uniquely identified. One 
instruction might result in multiple violations 
in different MMUs, so that the segment trap 
software might have to deal with several MMUs 
to process the trap. 

The other two control registers in the MMU 
are the Segment Address Register (SAR), 
which points to one of the 64 segment descrip- 
tors, and the Descriptor Selection Counter 
Register. Commands to read or write a seg- 
ment descriptor use the SAR pointer to select 
which descriptor is to be accessed. This 
register has an auto- incrementing capability 
for accessing consecutive descriptors in suc- 
cession without having to reload the SAR. Thus 
if descriptors through 4 are to be modified, 
the SAR is initialized to and then auto- 
incremented to point to descriptors, 1, 2, 3 
and 4 in succession. 

The Segment Descriptor Number is a 6- bit 
field that contains the address of the descriptor 
within the MMU. If the MMU holds segments 
64 through 127 (that is, if the URS flag is set), 
the segment named 64 is accessed when the 
SAR number field is 0. This is a result of the 
6-bit limit of the descriptor number field. The 
field indicates the 6 least- significant bits of the 
logical segment descriptor number. 



Figure 8. MMU Control Registers 
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Control Segment Descriptors consist of four bytes; 

Registers the Descriptor Selection Counter indicates 

(Continued) which byte is being accessed during a com- 
mand (commands to the MMU can read or 
write only one byte at a time). A counter value 
of indicates the high-order byte of the base 
address is being accessed, 1 indicates the low- 
order byte of the base address, 2 indicates the 
limit field, and 3 indicates the attribute field. 



This counter is used by MMU commands that 
access multiple bytes within a descriptor. In 
general, the counter is handled automatically 
by the MMU commands. Only when a com- 
mand could be interrupted — and intervening 
MMU commands issued — should this register 
be saved and later restored by the interrupting 
program. 



Status Six 8-bit registers contain information useful 

Registers in recovering from memory trap conditions 

(Figure 9). The Violation Type Register 
describes the conditions that generated the 
segment trap. The Violation Segment Number 
and Offset Registers contain the segment 
number and upper byte of the segment address 
offset for the logical address that caused 
the segment trap. The Instruction Segment 
Number and Offset Registers contain the seg- 
ment number and uper byte of the segment 
address offset for the last instruction before the 
segment trap was issued. The Bus Cycle Status 
Register records the status of the bus at the 
time the trap condition was detected. 

Only violations caused by CPU access have 
trap information stored in the status registers; 
DMA violations cause Suppress to be asserted, 
but the Status Registers are not altered. Thus if 
a DMA violation occurs between a CPU viola- 
tion and entry to the trap service routine, the 
service routine still has the CPU trap informa- 
tion available to process the trap. It is the 
responsibility of the DMA device to save 
enough information in the event of a violation 
so that a software DMA violation service 
routine can process the violation correctly. 
Eight flags in the Violation Type Register 
describe the cause of the segment trap. Four 
flags correspond to access protection modes in 
the segment descriptor attribute mode. A read- 
only violation sets the RDV flag, a system-only 
violation sets the SYSV flag, a CPU access to a 
CPU-Inhibit segment sets the CPUIV flag, an 
execute-only violation sets the EXCV flag. 

Three flags correspond to addressing viola- 
tion or warnings. The Segment Length Viola- 
tion Flag (SLV) is set whenever the offset of the 
logical address falls outside the memory space 
allocated to the segment. The Primary Write 
Warning Flag (PWW) is set whenever a write 
occurs in the last 256 bytes of a segment whose 
Direction And Warning Flag is set (that is, for 
segments being used as stacks where the top of 
the stack is within 256 bytes of the allocated 
memory space of the segment). The Secondary 
Write Warning Flag (SWW) is similar to the 
PWW flag, only it is set when the CPU is in 
system mode, a stack push is being performed 
to a segment with a Direction And Warning 
Flag set, and some other addressing violation 
or warning has occurred (the EXCV, CPUIV, 
SLV, SYSV, RDV or PWW flags have been 
set) . When the SWW flag is set it indicates 



that the system stack is in danger of overflow- 
ing its allotted memory. Once the SWW flag is 
set, further write warnings are suppressed. 
This prevents the system from repeatedly 
being interrupted for the same warning while 
it is in the process of eliminating the cause 
of the warning. 

The final violation-type register flag to be 
discussed is the Fatal Condition Flag (FATL). 
This flag is set when any other flag m the 
violation type register is set and either a viola- 
tion is detected or a write-warning condition 
occurs in normal mode. This flag is not set 
during a stack push in system mode that 
results in a warning condition. This flag 
indicates that a memory access error has 
occurred in the trap processing routine. Once 
this flag has been set, no Trap Reguest signals 
are generated on subsequent violations. 
However, Suppress signals are generated on 
this and subsequent CPU violations until the 
FATL flag has been reset. 

The Bus Cycle Status Register contains infor- 
mation pertaining to the status of the bus when 
a trap condition is detected. This includes 
CPU Status (ST0-ST3), plus flags indicating 
whether a read or a write_was being performed 
and whether or not the N/S line was asserted. 

The Violation Segment Number and Offset 
Registers record the first logical address to 
cause a trap. Only the high-order byte of the 
offset is saved, however, so that external sup- 
port circuitry is needed to save the low-order 
eight bits of the logical address offset. If the 
trap occurred during the instruction fetch 
cycle, this information is the logical address of 
the instruction; otherwise it indicates the 
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Status logical address of a data item which was to be 

Registers accessed. 

(Continued) The Instruction Segment Number and Offset 

Registers record the logical address of the last 
instruction fetch that occurred before the trap. 
Only the high-order byte of the offset is saved, 
however, so external support circuitry is need- 
ed to save the low-order eight bits of the offset. 
If an instruction fetch caused the trap, these 



registers indicate the logical address of the 
previous instruction. Such information is useful 
if the preceding instruction was a branch 
instruction to an invalid address since — in this 
case — these registers indicate which branch 
instruction led to the erroneous situation. If a 
data reference caused the segment trap, then 
these registers indicate the logical address of 
the instruction that specified the illegal access. 



Stack Segments are specified by a base address 

Segments and a range of legal offsets to this base 

address. On each access to a segment, the off- 
set is checked against this range to insure that 
the access falls within the allowed range. If an 
access outside the segment is attempted, a 
Trap Request and a Suppress signal are 
generated. 

Normally the legal range of offsets within a 
segment is from to 256N + 255 bytes, where 
0<N<255. (N is the value in the limit field of 
the segment descriptor.) However, a segment 
may be specified so that legal offsets range 
from 256N to 65,535 bytes, where 0<N<255. 
The latter type of segment is useful for stacks 
because the Z8001 stack- manipulation instruc- 
tions cause stacks to grow toward lower 
memory locations. Thus, when a stack grows to 



the limit of its allocated segment, additional 
memory can be allocated on the correct end of 
the segment. As an aid in maintaining stacks, 
the MMU detects when a write is performed to 
the lowest allocated 256 bytes of these 
segments and generates a Trap Request. No 
Suppress signal is generated so the write is 
allowed to proceed. This write warning can 
then be used to indicate that more memory 
should be allocated to the segment. 

The DIRW flag indicates that a segment is to 
be treated in this special way by the MMU. 
When the DIRW flag is set, the range of 
allowed offsets is from 256N to 65,535 bytes 
and writes into the range 256N to 256N + 255 
generate Segment Trap but not Suppress, 
indicating a write warning. 



Segment The Z8010 MMU generates a Segment Trap 

Trap and whenever it detects an access violation or a 

Acknowledge write warning condition. In the case of an 

access violation, the MMU also activates Sup- 
press. Suppress can be used to inhibit memory 
writes and to request that special data be 
returned on a read access. Segment Trap 
remains Low until a Trap Acknowledge signal 
is received. If a violation occurs, Suppress is 
asserted for that cycle and all subsequent CPU 
memory references until the end of the instruc- 
tion. Intervening DMA cycles are not sup- 
pressed, however, unless they generate a 
violation. Violations detected during DMA 
cycles cause Suppress to be asserted during 
that cycle only; no segment trap requests are 
ever generated during DMA cycles. This is 
because the CPU would not be able to respond 
to these traps until the conclusion of the DMA 
cycle. 

Segment traps to the Z8001 CPU are handled 
similarly to other types of interrupts. To ser- 
vice a segment trap, the CPU enters a segment 
trap acknowledge cycle. The acknowledge 
cycle is always preceded by an instruction 
fetch cycle that is aborted. The MMU has been 
designed so that this dummy instruction fetch 
cycle is ignored. During the acknowledge 
cycle, all enabled MMUs use the Address/Data 
lines to indicate their status. An MMU that has 
generated a Segment Trap request outputs a 1 



on the A/D line associated with the number in 
its ID field. An MMU that has not generated a 
segment trap request outputs a on its 
associated A/D line. A/D lines for which no 
MMU is associated remain 3-stated. During a 
segment trap acknowledge cycle, an MMU 
uses A/D line 8 + i if the content of its ID 
field is i. 

Following the acknowledge cycle, the CPU 
automatically pushes the program status words 
and program counter onto the system stack, 
and loads a new program status word and pro- 
gram counter from the program status area. 
The Segment Trap line is reset during the seg- 
ment trap acknowledge cycle, and no Suppress 
signal is generated during the stack push. If 
the store creates a write warning condition, a 
segment trap request is generated and is ser- 
viced at the end of the context swap; the SWW 
flag is also set. Servicing this second Segment 
Trap request also creates a write warning con- 
dition, but — because the SWW flag is set — no 
Segment Trap request is generated. If a viola- 
tion rather than a write warning condition 
occurs during the context swap, the FATL flag 
is set rather than the SWW flag. In this case, 
subsequent violations cause the Suppress to be 
asserted but not Trap Request. Without the 
SWW and FATL flags, trap processing routines 
that generate memory violations would 
repeatedly be interrupted and called to pro- 
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Segment cess the violations they create. 
Trap and The CPU routine to process a trap request 

Acknowledge should first check the FATL flag to determine 

(Continued) if a fatal system error has occurred. If not, the 



SWW flag should be checked to determine if 
more memory is required for the system stack. 
Finally, the trap itself should be processed and 
the violation type register reset. 



Commands When a memory management system must 

to the MMU read or change information m the MMU to 

respond to a segment trap or to re-organize the 
physical memory, it can issue control com- 
mands to the MMU. These commands fall into 
two generic categories: reset commands and 
read/write commands. Reset commands are 
simply orders to the MMU to set or clear 
specified fields. For these commands, the 
Z8001 Special I/O output command can be 
used with the destination field set to be the 
MMU command code corresponding to the 
desired action. 

Read and write commands are slightly more 
complicated because they consist of both com- 
mands and data. Such commands to the MMU 
are issued using the Z8001 Special I/O instruc- 
tions. These instructions have a source and a 
destination field. For an input instruction, the 
source field contains an MMU command code 
and the destination field indicates where in 
primary memory the data is placed. For an 
output instruction, the destination field con- 
tains an MMU command and the source field 
indicates where the data to be written into the 
MMU resides in memory. 

The high-order byte of the command con- 
tains the opcode for that command; the low- 
order byte of the command can be used to 
specify the particular MMU to be accessed. 
The MMU does not receive information on 
AD0-AD7, so external circuitry must decode 
information on these lines during the Special 
I/O commands and then select a particular 
MMU. The encoding of the low-order byte is 
dependent upon the system implementation. 
This paper always uses the convention that 
bit 1 specifies MMU number 1. 

The reset commands to the MMU are: Reset 
Violation Type Register, Reset SWW Flag In 
Violation Type Register, and Reset Fatal Flag 
In Violation Type Register. Resetting the Viola- 
tion Type Register is similar to a hardware 
reset in that it clears this register and returns 
the internal control of the MMU to an initial 
state (as if no violation had occurred since 
system initialization). Resetting the SWW flag 
or the FATL flag in the Violation Type Register 
clears these flags. 

Two other commands are similar to reset 
commands in that they have no data associated 
with them. These are Set All CPU-Inhibit Flags 
in the segment attribute fields and Set All 
DMA-Inhibit Flags in the segment attribute 
fields, both of which cause all segment 



descriptors in the MMU to have the CPUI or 
DMAI flags set, respectively. These two set 
commands can be useful in initializing address 
translation tables or when swapping between 
tasks. For example, when swapping between 
tasks the Set All CPUI Flags command 
automatically makes the previous task's 
segments inaccessible to the next task, unless 
the system explicitly initializes the segment 
attribute field in these segments. 

As an example of using the Special Output 
instruction SOUT to control an MMU, consider 
resetting the fatal flag of MMU #1. The MMU 
command opcode for this is "%14" (% denotes 
hexadecimal). The assembler syntax for the 
SOUT instruction is "SOUT destination field, 
source field" so that the instruction to reset the 
fatal flag of MMU #1 is "SOUT %1402, RO." 
Specifying register in this instruction is an 
arbitrary choice — the content of this register is 
placed on the A/D lines during the data phase 
of the SOUT instruction, but it is ignored by 
the MMU. The low-order byte of the command 
(the destination field of the instruction) en- 
codes which MMU is to reset its fatal flag. The 
convention followed in this paper is that MMU 
1 is specified by setting bit i in the low order 
byte of the command. (Bit 1 set is hex u %02.") 

The rest of the MMU commands consist of 
both operation and data. The following internal 
registers can be read or written: the Mode 
Register, the Segment Address Register, the 
Descriptor Registers and the Descriptor Selec- 
tion Counter Register. A Descriptor Register 
can be read or written as a whole, or selected 
subfields can be accessed. In addition, by 
using the auto- increment feature of the Seg- 
ment Address Register, successive Descriptor 
Registers can be accessed, or a selected field 
within successive Descriptor Registers can be 
accessed. For example, one Special I/O com- 
mand in block mode could read a number of 
segment attribute fields. This is useful in deter- 
ming which segments have been modified. 

As an example of using the Special Output 
instruction SOUT to write data into an MMU, 
consider writing the contents of Register 6 into 
the Mode Register of MMU #2. The opcode for 
this command is "%00" and so the command is 
"SOUT %0004, R6." Here the high-order byte 
of the destination field contains the opcode 
and the low-order byte has bit 2 set (hex 
adecimal 4 if 0100 in binary) indicating 
MMU #2. 
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Commands Certain MMU internal registers can only be 

to the MMU read — there is no corresponding write instruc- 
( Continued) tion. This is because these registers contain 

information relating to a detected violation and 
thus it is not necessary to be able to write into 
these registers. These registers are the Viola- 
tion Type Register, the Violation Segment 
Number Register, the Violation Offset Register, 



the Instruction Segment Number Register, the 
Instruction Offset Register and the Violation 
Bus Status Register. Although the Violation 
Type Register cannot be written, it should be 
noted that it can be cleared and that two of its 
flags can be individually cleared: the SWW 
flag and the FATL flag. 



Direct DMA operations may occur between Z8001 

Memory machine cycles and can be handled through 

Access the MMU. The MMU permits DMA in either 

the System or Normal Mode of operation. For 
each memory access, segment attributes are 
checked and — if a violation is detected— a 
Suppress signal is generated. Unlike a CPU 
violation, which automatically causes Suppress 
signals to be generated on subsequent memory 
accesses until the next instruction, DMA viola- 
tions generate a Suppress only on a per- 
memory-access basis. The DMA device should 
note the Suppress signal and record sufficient 
information to enable the system to recover 
from the access violation. No Segment Trap 
Request is ever generated during DMA (hence 
warning conditions are not signaled). There 
are no trap requests because the CPU would 
not acknowledge the request until the end of 
the DMA cycle. 



At the start of a DMA cycle, the DMASYNC 
line must go Low, indicating to the MMU the 
beginning of a DMA cycle. A Low DMASYNC 
inhibits the MMU from using an indeterminate 
segment number on lines SN0-SN6. When the 
DMA logical memory address is valid, 
DMASYNC must be High on one rising edge of 
Clock and the MMU then performs its address- 
translation and access- protection functions. 
Upon the release of the bus at the termination 
of the DMA cycle, DMASYNC must again be 
High. After two clock cycles of DMASYNC 
High, the MMU assumes that the CPU has con- 
trol of the bus and that subsequent memory 
references are CPU accesses. The first instruc- 
tion fetch occurs at least two clock cycles after 
the CPU regains bus control. During CPU 
cycles, DMASYNC should always be High. 



Hardware The MMU can be reset by either hardware 

and or software mechanisms but note that they 

Software have different effects. A hardware reset occurs 

Reset on the falling edge of the Reset input; a soft- 

ware reset is performed by an MMU command. 
A hardware reset- clears the Mode Register, 
Violation Type Register and Descriptor Selec- 
tion Counter. If the Chip Select line is Low 
while Reset is Low the Master Enable Flag in 
the Mode Register is set to 1 . All other 
registers are undefined. After rese t, th e A/D 
and A lines are 3-stated. The SUP and SEGT 



open-drain outputs are not driven. If the 
Master Enable Flag is not set during reset, 
the MMU does not respond to subsequent 
addresses on its A/D lines. To enable an MMU 
after a hardware reset, an MMU command 
must be used in conjunction with Chip Select. 

A software reset occurs when the Reset 
Violation Type Register command is issued. 
This command clears the Violation Type 
Register and returns the MMU to its initial 
state as if no violations or warnings had 
occurred. 



Multiple-MMU Z8010 MMU architecture supports system 
Configur- configurations that use more than one 

ations MMU. Multiple MMU devices can be used 

either to manage 128 CPU segments rather 
than the 64 supported by one MMU, or to 
manage multiple translation tables. 

The Z8001 CPU generates logical address- 
es that can specify up to 128 different seg- 
ment names. Because the MMU contains 
only 64 Segment Descriptor Registers, two 
MMUs are needed to perform address trans- 
lation for 128 logical segments. Systems 
designed with only one MMU device still 
have the power and flexibility offered by 
memory management, although tasks in 
such a system are restricted to manipu- 



lating only 64 logical segment names. These 
names must either be through 63 or 64 
through 127. If the MMU in a single-MMU 
configuration is set to translate segment names 
in one range and the CPU generates a logical 
segment name in the other range, the MMU 
does not perform address translation and no 
physical memory location is output. In this 
case, no request is made to memory. There- 
fore, a single-MMU configuration should have 
additional external logic to detect erro- 
neous segment names and generate a Segment 
Trap and Suppress signal. 

The Upper Range Select flag (URS) is 
used in multiple MMU configurations to 
indicate which group of logical segment names 
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Multiple-MMU are to be translated by an MMU. When this 
Configur- flag is set, the Segment Descriptor Registers in 

ations the MMU are used in translating logical 

(Continued) addresses in the range 64 through 127. When 
the flag is clear, the range is through 63. 
Thus the URS flag corresponds to the most 
significant bit (bit 6) in the logical segment 
names that the MMU translates. Because this 
flag is under program control, the range of 
logical segment names can be changed during 
execution in System Mode. 

MMU architecture also supports multiple 
segment translation tables. This feature is 
useful when separate tables are maintained for 
different tasks. Each task has its own table and 
switching between tasks requires enabling the 
appropriate MMU devices. In contrast, systems 
with only one translation table must either 
restrict the logical segment names that an 
individual task can use, or change the 
Descriptor Register entries whenever tasks are 
swapped. Two flags jn the Mode Register, 
together with the N/S signal, are used in multi- 
ple table configurations. 

The Multiple Segment Table (MST) flag 
indicates whether the configuration is being 
used to support multiple tables. When this flag 
is set, the MMU will compare the N/S line 
against the Normal Mode Select Flag (NMS) 
before generating a physical memory location 
on its Address lines. When the line and the 
flag match (both asserted or both de-asserted), 
the MMU is enabled and an address translation 
is performed (assuming the URS flag matches 
the most significant bit in the logical segment 



name). If the N/S line fails to match the state 
of the NMS flag, no translated address is 
generated by the MMU. The MST flag and the 
NMS flag are under program control and can 
be changed in System Mode. 

The simplest multiple translation table con- 
figuration has one table for Normal Mode 
access and one for System Mode access. In 
such a configuration, the Multiple Table Flag 
is set in all MMUs and the N/U \me\oi each ^ 
MMU receives its input from the N/U output of 
the Z8001 CPU. MMUs containing descriptors 
of system segments have the NMS flag clear, 
and those containing descriptors to be used in 
Normal Mode have the flag set. When the 
Z8001 is in System Mode, the N/S line is Low 
and it matches the NMS flag in those MMUs 
whose Descriptor Registers contain system seg- 
ment information. Therefore, these MMUs are 
used in address translation for system 
references. 

When the Z8001 is in Normal Mode, the N/S 
line is High and it matches the NMS flag in 
those MMUs whose Descriptor Registers con- 
tain user segment information. Consequently, 
these MMUs are used in address translation for 
user segments. In this configuration, system 
segments are separated from user segments. 
When the Z8001 changes from Normal to 
System Mode of operation, the appropriate 
translation table is automatically selected. A 
more elaborate example of a configuration with 
multiple translation tables is given in the next 
section. 



Examples This section describes two Z8001-Z8010 con- 

figurations: one contains two MMUs and one 
address translation table; the other contains 
seven MMUs and four address translation 
tables. These examples are given in suf- 
ficient detail to illustrate some of the major 
ideas in constructing memory- management 
systems around the Z8010 MMU. High-level 
block diagrams illustrate some of the major 
features of typical hardware configurations 
and short programs illustrate software tech- 
niques for using the MMU. 

The first example system is the two- MMU 
configuration illustrated in Figure 10. The two 
MMUs are called MMU #1 and #2, and they 
are selected during a command cycle by ADj 
and AD2 being Low, respectively. Since a 
Special I/O instruction is being used bit must 
always be zero. Thus, when a low- order byte of 
a command is "%02," MMU #1 responds; 
when it is u %04," MMU #2 responds; and 
when it is u %06," both MMUs respond. (Note 
tha t ADj is inverted before attachment to the 
CS pin.) 

The A/Di line, which controls MMU #1 
through the Chip Select input, is first com- 



bined with the Reset line. This allows the 
Master Enable Flag to be set upon system 
initialization, so the logical addresses gen- 
erated by the CPU are passed to the physical 
memory. This is done because — upon reset — 
the mode register is otherwise cleared, the 
Translate Flag is clear and addresses pass 
through the MMUs untranslated. The bootstrap 
program can therefore reside in absolute 
memory locations in the physical memory. If 
the Reset line is not an input to the Chip 
Select line, the Master Enable Flag would not 
be set during system initialization and the CPU 
would not be able to address memory through 
the MMUs. 

Note that there is a direct path from the 
CPU and DMA to the system bus. This path 
is used during I/O and memory refresh 
because the MMUs are quiescent during these 
cycles. It is also used for data on memory 
reads and writes. Also, note that the Suppress 
line goes both to the memory, where it can be 
used to protect the memory from erroneous 
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Examples writes, and back to the DMA device to save 

(Continued) information upon the event of a DMA access 
error. 

Of further interest in the example, address 
latches are used to buffer addresses between 
the Z8001 and a demultiplexed bus. This is 
required to demultiplex the address and data 
onto the bus. The address latch for ADs-ADjs 
may not be needed if the I/O device does not 
use separate address and data lines. 

A detailed example indicates how such a 
system could be used. First, consider setting 
Segment Descriptor Register 65 to point to a 
read-only segment of 768 bytes starting at 
memory location % 115200. The segment is to 
be accessed in Normal Mode. The Descriptor 
Register should be % 115202 01. The first two 
bytes, %1152, indicate the starting location of 
the segment (note that the low-order byte of 
the memory address is all zeros and is not 
stored in the Descriptor Register). The third 
byte, %02, indicates that three blocks of 256 
bytes have been allocated to this segment. The 
fourth byte, %01, indicates that only the read- 
only segment flag has been set. 



To write this descriptor into the MMU, a 
copy of the descriptor should be created in 
primary memory and a Special I/O block 
transfer instruction used. The SOTIRB instruc- 
tion can be used for this. 

This instruction has the assembler syntax 
"SOTIRB destination, source, count register" 
where both the destination and source are 
registers. The destination register contains the 
command to the MMU, the memory location 
pointed to by the source register contains the 
first byte of the data to be transferred, and the 
Count Register contains the number of bytes to 
be transferred. 

The opcode to load the Descriptor Register 
is U %0B". Segment Descriptor Register 65 is 
Segment Descriptor Register 1 of MMU #2, so 
the MMU command is "%0B04". 

To specify which Segment Descriptor 
Register to write, it is necessary to load the 
Segment Address Register of MMU #2 with 1. 
The MMU opcode to do this is xx %01" and so 
the command is xx %0104." The segment 
number (in this case 65) is a parameter to the 
example routine, passed in register 0. The 



IQSA0K 



1*001 

CPU 



m 



DMA 



WOP 

mmu mm 



16 AD0-AD15 



=^£> 



3D- 



1*010 
MMU 



e§ §eg 



M^ 



—H 



m Hot 



Figure 10. A Dual-MMU Configuration 
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Examples 

(Continued) 



OVER: 



NEXT: 



BIT 
JR 


RO, #6 
Z, OVER 


SOUTB 
LD 


9/00104, RHO 
Rl, #%0B04 


JR 


NEXT 


SOUTB 
LD 


%0102, RHO 
Rl, #%0B02 


LD 
SOTIRB 


RO, #4 

@R1, @RR2 ; RO 



•Test to see if Descriptor Register is in MMU #1! 
lor MMU #2! 

!Set SAR m MMU #2! 
[Prepare to write descriptor! 



!SetSARinMMU#l! 

! Prepare to write descriptor! 

!Load count field — 4 bytes! 
.'Write descriptor! 



descriptor to be written is another parameter to 
this routine: RR2 contains the address in 
memory where this information resides. The 
SOUTB instruction has a similar syntax to the 
SOTIRB instruction explained previously 
except that it writes one byte instead of a 
series of bytes, and the destination I/O address 
is in the instruction itself instead of in a 
register specified by the instruction. 

The routine on this page initializes the Seg- 
ment Descriptor. Its parameters are found in 
Register RO, which contains the segment 
number to be written, and in Register RR2, 
which points to the descriptor information in 
primary memory. Registers RO through R3 are 
used by this routine. 

Now suppose that the user tries to write into 
location < <65> >%9328. This causes a seg- 
ment trap both because of the write to a read- 
only segment and because the access exceeds 
the segment limit. At the end of the instruction 
that has the illegal memory access, the CPU 
acknowledges the trap. During the trap 
acknowledge cycle, MMU #2 asserts ADiq 
(assuming its ID field is "010") and this infor- 
mation is placed on the system stack for the 



trap-handling routine. 

The trap-handling routine reads the violation 
information registers from the MMU. The viola- 
tion type register contains xx %05" indicating 
both a length violation and a read-only viola- 
tion. The Violation Bus Status Normal Register 
contains xx %28". The first nibble indicates a 
write in Normal Mode was in progress and the 
second nibble indicates a memory data access 
cycle was in progress. The violation segment 
register contains "%41" indicating segment 1 
of MMU #2 caused the violation (which is seg- 
ment number 65), and the violation offset 
register contains "%93" indicating the high- 
order byte of the logical address offset. The 
operating system can then issue an error 
message to the user indicating a read-only 
violation to segment 65. Using the program 
counter that was stacked when the segment 
trap was acknowledged, the system can also 
indicate the next instruction that was to be 
executed. Note that in this system the low- 
order byte of the violation offset is lost. This 
condition is corrected in the next example 
system. 
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Figure 11. 16-MMU Configuration 



Figure 11 gives a high-level diagram of the 
second system to be discussed. This configura- 
tion contains 16 MMUs, and the A/D lines 
select the appropriate MMU when in Com- 
mand mode. The major innovation in this 
example, aside from the additional MMUs, is 
the latch that retains the least significant byte 
of an address offset when a violation is 
detected. This latch is enabled when a seg- 
ment trap is generated by an MMU and holds 
the low-order byte of the address that 
generates an access violation. 

In addition, external decoding logic for 
selecting one MMU Chip Select line is indi- 
cated. Seven MMUs is the limit in one con- 
figuration without additional decoding logic 
for selecting one MMU Chip Select line. (The 
reason why ADq cannot be used to control an 
eighth MMU is due to the Special I/O input 



convention of the CPU. When the CPU inputs 
a byte of information and ADo is asserted, the 
data is taken from ADo-AD?, which are not 
driven by the MMU.) 

Switching Tables in a 16-MMU System. 

The 16-MMU configuration can support a 
memory management system designed with two 
MMUs permanently allocated to the operating 
system and the others allocated in pairs to dif- 
ferent user tasks. Thus, seven user tasks can 
have translation tables resident in the 14-user 
MMUs, and switching between active tasks 
requires the appropriate MMUs to be enabled 
and disabled. This selection process can be 
effected by manipulating the Master Enable 
(MSEN) flags in the mode registers of the 
appropriate MMUs. 
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(Continued) 



The routine performs the selective enabling 
of MMUs required by a task swap. This routine 
disables all user MMUs (thus disabling the cur- 
rently enabled user MMUs), then enables the 
appropriate pair. (The system pair is always 
enabled.) The code selecting the new task is 
passed in register Rl; it contains %n, if task n 
is to be dispatched. 

Two peculiarities of this example are worth 
noting. First, each user ID number cor- 
responds to seven MMUs (for example, all 
upper-range user MMUs). The Segment Trap 
processing routine has to take this into 
account. Second, the Chip Select code is 
assumed to be as follows: 





AD0-AD7 


MMU Selected 


System: 


02 


#1 ID = 0, URS = 




04 


#2 ID=1,URS = 1 


User 0: 


08 


#3, ID = 2, URS = 




10 


#4,ID = 3, URS = 1 


User 1: 


18 


#5, ID = 2, URS = 




20 


#6, ID = 3, URS = 1 


User 2: 


28 


#7, ID = 2, URS = 




30 


#8, ID = 3, URS=1 


User 6: 


68 


#15,10 = 2, URS = 




70 


#16, ID = 3, URS = 1 


It is also assumed that %F8 will select al 


user MMUs. 







CLR 


R0 


SOUT 


%00F8,R0 


SLA 


Rl,#l 


LD 


RlJABLE(Rl) 


LDA 


RR2,DATA 


SOUTIB 


@R1,@RR2,R0 


INC 


Rl,#8 


SOUTIB 


@R1,@RR2,R0 


END: 




DATA: 


BYTES(%DA,°, 


TABLE: 


WORDS (%8,° 



IClear R0! 

! Disable all user MMUs by clearing their mode registers! 
! Multiply Rl by 2 — the number of bytes in a memory word! 
!Get the command word (opcode always %00) for user n, 

URS = 0! 

!Get the new mode register bit pattern (%DA)! 
!Send %DA to lower- range MMU and increment RR2 to 

DATA +1! 

! Command word for URS = 1 ! 
!Send %FB to upper range MMU! 



Program to Switch Tables 



MMU 

Command 

Summary 



Opcode 


Operation 


Opcode 


Operation 


00 


Read/Write Mode Register 


OC 


Read/Write Base Field And 


01 


Read/Write Segment Address 




Increment SAR 




Register 


0D 


Read/Write Limit Field And 


02 


Read Violation Type Register 




Increment SAR 


03 


Read Violation Segment 


0E 


Read/Write Attribute Field 




Number 




And Increment SAR 


04 


Read Violation Offset (high 


OF 


Read/Write Descriptor And 




byte) 




Increment SAR 


05 


Read Bus Cycle Status Register 


10 


Reserved 


06 


Read Instruction Segment 


11 


Reset Violation Type Register 




Number 


12 


Reserved 


07 


Read Instruction Offset (high 


13 


Reset SWW Flag In VTR 




byte) 


14 


Reset FATL Flag In VTR 


08 


Read/Write Base Field In 


15 


Set All CPU-Inhibit Flags 




Descriptor 


16 


Set All DMA-Inhibit Flags 


09 


Read/Write Limit Field In 


17-lF 


Reserved 




Descriptor 


20 


Read/Write Descriptor Selector 


0A 


Read/Write Attribute Field In 




Counter Register 




Descriptor 


21-3F 


Reserved 


0B 


Read/Write Descriptor (all 
fields) 
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An introduction to 
memory management 



Once used only on the largest computer systems, 

memory-management techniques will soon be used on a 

variety of high-level microprocessor -based systems 



The declining cost per bit of memory has 
led to systems with even larger 
memories, and the declining cost of 
logic has led to more powerful pro- 
cessors. Together, these two trends pro- 
mote the sophisticated use of large 
memories, based on techniques com- 
monly referred to as memory manage- 
ment. Automated memory -management 
systems date back to the Atlas computer 
project at Manchester University in the 
late 1950s. During the 1960s the concept 
was exploited in a number of time- 
sharing machines (e.g. the Scientific 
Data Systems 94Q, General Electric 645, 
Digital Equipment Co. PDP-10), and 
during the 1970s was highly publicised 
in its manifestation as virtual memory 
(IBM 370). Until fairly recently, memory 
management has been associated only 
with large mainframe computers, but 
with the 1978 introduction of Digital 
Equipment's VAX 1 1 'super mini', the 
concept has invaded the minicomputer 
market. Now, with the advent of single- 
chip memory-management units such as 
that available with the Zilog Z8000 pro- 
cessor, the concept is about to arrive in 
microprocessor -based systems. 

Memory management has two func- 
tions: the efficient allocation and 
reallocation of memory space to ex- 
ecuting tasks so as to optimise overall 
memory usage; and the protection of 
memory contents from unintended or 
unauthorised accesses by executing 
tasks. To keep overall memory usage op- 
timised as demands on memory con- 
stantly change, dynamic relocation of 
taslfs during their execution may be 
necessary, and this is accomplished by 
an address-translation mechanism. The 
restriction of memory access to prevent 
unintended or unauthorised accesses is 
accomplished by memory-attribute 
checking. Both operations occur with 
each memory access made during the 
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execution of a program, and both are 
transparent to the user. 

Address translation simply means 
treating the memory addresses 
generated by the program as logical or 
virtual addresses to be translated into 
actual physical-memory addresses 
before dispatching the memory-access 
requests to the memory unit. Memory - 
attribute checking means that each area 
of memory has associated with it infor- 
mation as to which tasks can access it 
and what types of access can be made by 
each task. Each memory reference is 
checked to ensure that the task has the 
right to access that location in the given 
fashion (for example, to read the con- 
tents of the location or to write data to 
that location). 

Instead of a conventional linear ad- 
dress space, more elaborate memory- 



management systems simulate a hierar- 
chical memory structure in which the 
memory consists of a collection of 
distinct memory areas, called segments. 
Access to this structured memory re- 
quires the specification of a segment and 
of an offset within that segment. Thus, in- 
stead of specifying, say, memory loca- 
tion 1050 m a linear address space, a 
task might specify memory location 5 in 
segment number 23. The actual location 
of the segment in the physical memory 
does not concern the task — the actual 
access is carried out via the address- 
translation mechanism, which is inform- 
ed of the actual location of the segment 
by the operating software. 

Generally, segments can be of 
variable size, within limits, and a user 
can specify the size of each segment to 
be used. Thus one user may be allocated 



user As personal 
memory space 



user Bs personal 
memory space 




1 In a multiuser system, each user is aware of only those memory segments in his own 
'personal' logical-memory space, and does not know where the segments are located in 
the system's physical memory 
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user As program 
(execute only) 
user Bs program 
(execute only) 
user Bs stack 
(stack read /write) 

user As data 
(read /write) 



user Bs data 
(read /write) 



system code 
(system execute 
only) 

system code 
(system execute 
only ) 



system tables 
(system read 
/write) 



user A's data 
(read /write) 



user B's program 
(execute only) 
user As program 
(execute only) 
user Bs data 
(read /write ) 
user Bs stack 
(stack read/ write 



2 Transparently to the users, the system's operating software 'maps' each user's (and its own) logical memory space into the physical 
memory, also applying memory-protection attributes to each segment. If changing demands on memory space make the original map- 
ping (a) no longer optimum, the system can dynamically relocate segments (Jb), again transparently to the users 



two segments, one of 2000 words for his 
Fortran program, and the other of 
10 000 words for his data. Another user 
might be allocated three segments, of 
3000, 6000 and 2000 words, respectively, 
for her Pascal program, data, and run- 
time stack. If the first user called his data 
segment Segment 5', then the first word 
in his data set would be accessed by the 
logical address (5,0), indicating seg- 
ment 5, offset 0. The memory- 
management system then translates this 
symbolic name into the correct physical- 
memory address. 

Fig. 1 gives a conceptual realisation of 



these two users' logical program spaces. 
The first user, user A, has his program 
segment called 'segment 6' and his data 
segment called 'segment 5'. The second 
user, user B, has her program segment 
called 'segment 5', her data segment 
called 'segment 12' and her stack seg- 
ment called 'segment 2'. Notice that both 
users have named one of their segments 
'segment 5', but they refer to different 
entities. This causes no problem since 
the system keeps the two memory areas 
separate. The situation is analogous to 
both users having an integer variable 
called 7* in their programs: the system 



realises that these are two separate 
variables stored in different memory 
locations. 

User A's data segment, 'segment 5', is 
10 000 words long. If he tries to 
reference word 10 050 of segment 5, he 
gets an error message from the 
operating software indicating that he has 
exceeded the allocation limit for seg- 
ment 5. Note that he does not accidental- 
ly access word 50 of segment 6; i.e. 
segments are logically distinct and 
unordered. A reference to one segment 
cannot inadvertently result in access to 
another segment. Thus, in this example, 



A virtual end to microprocessor memory limits 



All the 'super microprocessor' designs are based on 
the need to reduce software costs by facilitating pro- 
gramming, and one of the major causes of difficulty in 
programming any computer-like device is limitations 
on the size of available memory. By removing the 64 
kbyte limit imposed by earlier devices, the 'super 
micros' have eased this problem, but experience with 
larger, usually mainframe, computers suggests that 
the user's programming task will be simplified even 
more when, in the near future, microprocessors 
become capable of supporting virtual-memory opera- 
tion, which effectively removes all practical limits on 
memory size. 

Virtual-memory operation works by using relatively 
inexpensive secondary memory, such as that provid- 
ed by magnetic discs, to supplement the system's 
primary memory, which is necessarily built from 
relatively expensive random-access-memory com- 
ponents. However, since any program or item of data 
can only be accessed by the processor when held in 
the random-access primary memory, this can only be 
done by continuously 'swapping' blocks of program 
code or data between the two memories. This swapp- 
ing is carried out automatically by the processor's 



hardware and operating software, so that the opera- 
tion of the whole virtual-memory system is transparent 
to the user, who is aware only of having access to an 
extremely large personal memory space 

As example of the use of virtual-memory operation 
is given by Digital Equipment's VAX-11 advanced- 
architecture version of its PDP-1 1 minicomputer. As a 
full 32 bit machine, the VAX-1 1 is capable of address- 
ing over 4-3 x 10 9 bytes of memory, and the virtual- 
memory system operates to effectively give each pro- 
cess, no matter how many are concurrently active, 
acces to over 10 9 bytes of 'private' memory space. In 
practice, of course, not even the most demanding ap- 
plication requires any of its processes to have access 
to this huge amount of memory: thus the aim of 
removing all practical limitations on memory size has 
been achieved 

The VAX-11 processor implements its virtual- 
memory system by a relatively simple paging technique. 
The whole address space is divided into 512-byte 
'pages' that can be swapped independently between 
primary and secondary memory. Each logical address 
used in the system is composed of a 23-bit page 
number and a 9-bit offset. At each attempted access, 
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system code 

(system execute only) 



system code 

(system execute only) 



system tables 
(system read /write) 



shared data 
(read only) 

user A's program 
(execute only) 
user B's program 
(execute only) 
user B's stack 
(stack read /write ) 

user A's data 
(read /write) 



user Bs data 
(read /write) 



3 The memory-management system can also allow segments to be shared between users, such as a shared data segment meant for in- 
put to more than one user program. To prevent any one user from altering the shared data, the system marks the segment 'read only' 



user A is prevented from accidentally 
(or deliberately) accessing his program 
as though it were part of his data seg- 
ment. 

Fig. 2a illustrates one way that the 
operating software could arrange these 
segments in the physical memory. If 
demands on physical -memory space 
were to change, however, the operating 
software could dynamically relocate the 
segments (e.g. as shown in Fig. 26), the 
relocation being completely transparent 
to the two tasks. In each case, the arrows 
indicate the address-translation or 
memory -mapping functions from the 



logical -address space of the users to the 
physical-memory locations allocated to 
them. The Figure also indicates the ac- 
cess attributes associated with each 
user's segments. For example, program 
segments are execute only' and data 
segments are Vead/wnte'. Thus a user is 
prevented from executing a data seg- 
ment or writing into a code segment. 

Fig. 3 illustrates what happens when 
both users have access to the same data 
set in primary memory, say the results of 
a guestionnaire that both intend to 
analyse. Each user has a logical name 
associated with that data set to specify 



the segment in which the data set is to 
reside. Note that the two users have 
chosen to put the data set in different 
segments of their personal address 
spaces. The memory -mapping system 
translates these different segment names 
to the same physical memory locations. 
Thus user A's access to address (2,17) 
references the same physical memory 
location as user B's access to address 
(7,17). The shared data segment is mark- 
ed 'read only' to prevent either user from 
deliberately or accidentally changing 
the data. 
Before proceeding to the mechanism 



the system's memory-management unit checks to see 
if the desired page is in the primary memory, and if so 
translates the logical address to the appropriate 
physical address. If the page is not in primary 
memory, it is 'swapped in' from the disc. All this is 
relatively straightforward — the complication comes 
in during the design of the 'paging algorithm' by which 
the operating software decides which page currently 
in primary memory can most readily be 'swapped out' 
to free space for the incoming page. The efficiency of 
the whole system depends critically on the choice of 
the correct swapping algorithm, and in computer- 
science terms this choice is 'non-trivial', or in other 
words extremely difficult. 

With the forthcoming announcement of the Na- 
tional Semiconductor 16000 'super micro' range, 
virtual«memory operation of this kind will become 
feasible in microprocessor systems for the first time. 
The NS16082 memory-management unit (m.m.u.), 
which will act as a coprocessor to the NS16000 main 
processor, will support a paged system of virtual- 
memory operation rather like that used on the VAX-1 1 . 
Because of the NS16000*S use of 24-bit addresses, 
each virtual-memory space will be initially limited to 
only 16 Mbytes, but later expansion should increase 
this substantially, The m.m.u. will provide fast 



associative storage for active address-translation 
tables within its internal memory, using a cache ap- 
proach to ensure that only 5% of accesses require 
reference to the full translation tables stored in 
primary memory. On detecting that a required page is 
not in primary memory, it will send an 'abort' message 
to the main processor, which is equipped with a 
special hardware mechanism to 'roll back' its state to 
what it was at the start of the aborted instruction. Na- 
tional Semiconductor claims that, with these featues, 
and with an appropriate operating system to control 
them, the design of a full virtual-memory system 
should not be significantly more difficult than the 
design of any other microprocessor-based system. 

Will such virtual-memory microprocessor systems 
ever become widely used, however? One develop- 
ment that may make them extremely attractive is that 
of denser, less expensive, magnetic-bubble stores. A 
relatively inexpensive system could then be based on 
a 'super micro', a relatively small (say 128 kbyte) 
primary memory, and 1-2 Mbyte of fast non-volatile 
bubble storage. Such a system, occupying a single 
board, might well exhibit a performance approaching 
that of traditional mainframe systems. 

DENNIS MORALEE 
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Memory management comes to micros 



A survey of recent product announcements reveals 
that the microprocessor manufacturers all agree on 
the importance of providing memory-management 
facilities for the next generation of microprocessor- 
based systems All the new-generation 'super micro- 
processors' have been designed with the use of 
memory management in mind, and existing 
microprocessor families, such as the Texas In- 
struments 9900 range, are being extended by the pro- 
vision of 'add-on' memory-management units 
Although it might at first seem that the use of memory- 
management techniques could only be justified in 
specialised high-end applications, the low cost of the 
large-scale-integration hardware and packaged 
operating software now becoming available may soon 
make sophisticated memory management a common 
feature of even relatively modest micro-based 
systems 

With the exception of Intel, all the microprocessor 
manufacturers have decided to use the traditional 
minicomputer approach to providing memory- 
management facilities, which involves the use of 
separate memory-management units (m m u s) 
located between the processor and memory Using 
this approach, the m m u accepts memory-access re- 
quests from the processor on its input lines, performs 
address translation and memory-attribute checking as 
desired, then sends appropriately modified access re- 
quests to the memory via its output lines 

Typical of such m m u s is the Z8010 unit designed 
to provide memory-management facilities to systems 
based on the Zilog Z8000 microprocessor In opera- 
tion, the m m.u receives 23-bit logical addresses from 
the processor, these addresses consisting of a 7-bit 
segment number and a 16-bit offset These logical ad- 
dresses are then translated into 24-bit physical ad- 
dresses by using the segment number to address a 
64-line table held within the m m u , adding the 16-bit 
segment starting address thus retrieved to the top 8 
bits of the logical-address offset, and concatenating 
the lower 8 bits of the offset with the result of this addi- 
tion (see Figure) The m m u then sends this 24-bit 
physical address to memory to complete the access 

The use of a 7-bit segment number enables the 
Z8000 to divide its memory into a maximum of 128 
segments, a second m m u being used in parallel with 
the first if more than 64 segments are actually going to 



be in use at any one time These segments may be of 
variable length, up to the maximum of 64 kbytes im- 
posed by the 16-bit size of the offset, and may be 
located freely within the overall 8 Mbyte memory, sub- 
ject only to the restriction of the starting address be- 
ing a multiple of 256 bytes, a restriction imposed by 
the 16-bit size of the stored segment-starting ad- 
dresses Relocation of segments is achieved by the 
processor changing the contents of the appropriate 
entries in the m m u 's segment-address table, which 
it does by means of special input/output instructions. 

As well as providing for address translation, the 
m m u also checks the attributes of the addressed 
segment, which are stored, along with its starting ad- 
dress, in the internal 64-line table One attribute it 
always checks is the length of the segment, ensuring 
that the logical address provided does in fact lie within 
the declared segment boundaries. Other attributes 
relate to the type of access allowed, e g execute-only, 
read-only and read/write, and to check that the access 
being attempted does not violate these memory- 
protection attributes, the m m u needs to know for 
what purpose the processor is trying to access the 
specified segment This it determines by monitoring 
four status lines connected to the processor, which in- 
dicate, inter alia, whether the processor is trying to 
fetch an instruction from memory, to access data 
from memory, or to' manipulate a memory-based 
stack If the attempted access is not allowed by the 
segment's attributes, the m m u interrupts the pro- 
cessor via a special 'segment trap' line 

A unique feature of the Z8000 design is that the use 
of the four processor-status lines could be used to 
divide the system's memory additionally into special- 
purpose areas each capable of holding only one type 
of data Thus, completely separate memories could be 
provided for programs, data and stacks, and the 
■distinction between user and system operation could 
double- this to a total of six separate memories, each 
of which could be 8 Mbytes in length Whether any 
user would actually want to partition his system's 
memory in this rather inflexible way, however, re- 
mains to be seen 

The operation of the m m u , although based on fast 
h m o s logic, inevitably results in each memory ac- 
cess suffering a certain additional delay In the Z8000 
system, this delay is minimised by arranging for the 



of memory management, it is instructive 
to review the advantages of using this 
form of segmented address translation 
and attribute-based memory protection. 
The first advantage is that it permits the 
dynamic allocation of memory during 
the execution of tasks, i e tasks can be 
located anywhere in memory, and can 
be relocated as desired while their ex- 
ecution is suspended The address- 
translation mechanism provides this 
flexibility because the task deals ex- 
clusively with logical addresses, and 
hence is independent of the addresses of 
the physical-memory locations it ac- 
cesses Moving the task to different 
physical-memory locations requires that 
the address-mapping function bp chang- 
ed to reflect the change in physical 
memory location, but the task's code 
need not be modified Of course, this 
flexibility does incur the overheads in- 
volved in managing the various address- 
translation tables required by the 
operating software, but these are nor- 
mally outweighed by the advantages 
The second advantage is that it allows 



the sharing of common memory areas by 
different tasks This is accomplished by 
mapping different logical areas in dif- 
ferent tasks to the same physical-memory 
locations 

The third advantage is that it provides 
protection against certain types of 
memory access This is accomplished by 
associating accessing attributes with 
each logical segment, and by checking 
the type of access to see if each access is 
permitted 

The fourth advantage is that it detects 
obvious execution errors related to 
memory accessing This can be ac- 
complished by checking each access to 
a segment to see whether the address 
falls within the physical-memory area 
allocated to that segment. It could also 
include affixing a read/write attribute to 
data to prevent a task from trying to ex- 
ecute a data segment, and affixing an 
execute-only attribute to code segments 
to prevent a task from trying to read or 
write data to this segment Additionally, 
if a segment is used to hold a stack, the 
system could issue a warning to a task 
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when the stack approaches the allocated 
limit of the segment. The task could then 
request the operating software to 
allocate more memory to the stack 
before the stack overflows and creates a 
fatal error. 

The final advantage of such memory- 
management systems is that they 
separate user functions from system 
functions For processors that distinguish 
between a 'system' mode and a user' 
mode of operation, this goal can be ac- 
complished by associating a system-only 
attribute with operating -system segments 
so users cannot directly access the 
operating software and its data tables. 

As a final point, it should be noted 
how segmentation can be used to sup- 
port the development and execution of 
large, complex programs and systems. 
The concept of segmentation cor- 
responds to the concept of partitioning a 
large system into procedures and data 
structures, each procedure and data 
structure being associated with a 
separate segment. A task can then in- 
voke a procedure or subtask, or access a 
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processor to put the 7-bit segment number on its out- 
put lines one cycle ahead of the rest of the address 
This gives the m m u additional time to retrieve the 
appropriate segment-starting address and to check 
the appropriate segment attributes 

From this account of the m m u 's action, it will be 
seen that the Z8000 processor handles 23-bit logical 
addresses directly, each logical address comprising a 
segment number and appropriate offset These 23-bit 
addresses can be stored as 32-bit 'long words' in pairs 
of 16-bit registers or in adjacent 16-bit memory words, 
and can be manipulated by all the Z8000's built-in 



'long word' operations For more efficient manipula- 
tion of short (up to 256 byte) segments, shortened 
logical addresses consisting of 7-bit segment 
numbers and 8-bit offsets can also be used, these 
shortened addresses fitting within an ordinary 16-bit 
word 

Very similar memory-management facilities are 
said to be planned for Motorola's 68000 'super micro' 
The Motorola device, however, uses 24-bit logical 
memories to give a larger 16 Mbyte addressing range 

DENNIS MORALEE 



data structure, by referring to its logical - 
segment name. Access to these objects 
can be individually restricted by using 
the protection-checking mechanism of 
the memory -management system. 

Virtual memory 

With the memory-management 
systems considered so far, it has been 
assumed that the actual physical 
memory available is always large 
enough for all the users' logical -address 
space to be simultaneously mapped onto 
it. In fact, further advantages can result 
from making even this physical-memory 
space Virtual', and from mapping it in 
turn into a two-level memory space, part 
of which is held in a relatively small 
'true' physical memory, and part of 
which is held on a secondary -memory 
device such as a magnetic disc (Fig. 4). 

In operation, this virtual -memory ar- 
rangement relies on an extension of the 
address-translation scheme considered 
above. If a given segment is not current- 
ly in physical memory, the address - 
translation table indicates the fact, and 



links to a routine forming part of the 
operating software and capable of fet- 
ching the segment from secondary 
memory when needed. 

Whenever an access is made to a seg- 
ment missing from physical memory, the 
instruction execution is held in 
abeyance until the segment can be 
brought into the physical memory, and 
then the instruction is allowed to pro- 
ceed with the memory access. The ad- 
dress translation is then performed, ac- 
cess protection is checked, and the in- 
struction proceeds as if the segment had 
been in the physical memory at the 
begirthing of the instruction. Thus this 
technique of demand swapping, or 
segmented virtual memory, means that 
the segments will not in general reside in 
physical memory until a task actually 
tries to access it. 

Another technique of virtual -memory 
management is paging, which is also a 
method of partitioning a user's logical- 
address space and mapping it onto a 
two-level physical memory. Essentially, 
a paging system divides the logical 



memory into fixed-sized blocks, called 
pages. Like segments, the individual 
pages can be located anywhere in the 
physical memory, and a translation 
mechanism maps logical addresses to 
physical locations. There are two dif- 
ferences between paging and segmen- 
ting a logical memory. First, pages are 
of fixed size whereas segments are of 
various sizes. Second, under paging, the 
logical memory is still linear, i.e. a task 
accesses memory using a single number, 
rather than a pair as in segmentation. 

The major advantage of paging is in 
treating memory as blocks of fixed sizes, 
which simplifies allocating memory to 
users and deciding where to place the 
logical pages in physical memory. The 
major disadvantage of paging is the dif- 
ficulty of assigning different protection 
attributes to different areas in a user ad- 
dress space, because a paged memory 
appears homogeneous to the user and 
the operating system. Paging can, 
however, be combined with segmenta- 
tion to produce a memory -management 
system with the advantages of both pag- 
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4 In a virtual-memory system, the system's 'physical memory' is split between a relatively small random-access 'main' memory and a 
secondary-memory disc store. If a program attempts to access a segment not currently stored in main memory, the operating software 
retrieves it from the disc, and processing continues transparently to the user 



ing and segmentation, but at the cost of 
considerable extra complexity. 

Mechanics of memory 
management 

Essentially there are four issues in im- 
plementing a memory management 
system: how addresses are specified, 
how these addresses are translated, what 
attributes are checked for each access, 
and how the protection mechanism is im- 
plemented. 

Two approaches have traditionally 
been taken for specifying addresses in a 
segmented memory (for simplicity, only 
addresses in instructions are discussed 
here). The first way puts all the address- 
ing information in the instruction itself; 
i.e. each memory address in an instruc- 
tion contains both the segment name and 
the offset within the segment. The alter- 
native sets aside special registers that 
contain some of this information, for ex- 
ample, the segment name or the address 
in physical memory where the segment 
resides. 

The advantage of the latter approach 
lies in the fact that fewer bits are needed 
in an instruction to specify addresses. 
Thus programs may be shorter. Also, 
because there is reduced traffic between 
the memory and the processor for fet- 
ching shorter instructions, a program 
may be executed faster. 

On the other hand, these special 
registers must be manipulated to access 
more segments than there are registers, 
and this manipulation adds to the 
number of instructions, the program size 
and the execution time. In practice, 
these can de.-troy the advantages 



described above. If the special registers 
contain physical memory locations, 
these must be protected from user access 
to maintain the integrity of the system, 
and changing segments requires system 
calls which can be time consuming if too 
few registers are supplied. 

In either case, address translation is 
performed by adding the logical- 
segment offset to the address of the 
physical -memory location where the 
segment begins. Thus, when an address 
of the form (a,b) is presented to the 
translation mechanism, the segment 
name V is used to determine where seg- 
ment V resides in memory. Assume that 
it resides in locations 10000 to 25000. 
Then the actual memory location (a,b) is 
memory location 10000 ■*• b. The major 
option in implementing this type of ad- 
dress translation is in determining the 
segment's location in physical memory. 
When special registers have been set 
aside to contain the starting location of 
the segment instead of putting all ad- 
dress information in the instruction, the 
addressing mechanism is similar to us- 
ing the segment register as an index 
register or a base register. 

When logical addresses are either 
completely specified in the instruction or 
when the special register contains the 
segment's symbolic name rather than its 
physical -memory location, a table must 
be used to translate the segment's name 
into its physical -memory location. The 
table may have an associative capabili- 
ty, i.e. the segment name is presented to 
the table and it automatically returns the 
physical -memory location where the 
segment begins. Alternatively, the table 



could have one entry for every possible 
segment name, with the starting address 
of each segment in use stored as part of 
the table entry. 

A number of other segment attributes 
can also be stored in the address- 
translation table and checked during 
each access. One of these is the 
allocated length of the segment, and 
each access is checked to see if it falls 
within the bounds of the segment. 

Another type of attribute deals with 
ownership or class of ownership: tasks 
are grouped into classes, and only those 
in certain classes are permitted to own 
and therefore access a given segment. 
The simplest example is the 'system' ver- 
sus 'user' classification, where tasks are 
either one or the other, and which they 
are determines whether or not they can 
access a given segment. 

Other types of attributes that can be 
associated with a segment involve modes 
of accessing, for example 'read-only', 
'read/write' or execute-only'. Attributes 
can be either permissive or prohibitive; 
for example the 'write' attribute can 
mean writing to this segment is permit- 
ted' or writing to this segment is pro- 
hibited'. 

A final issue in the mechanics of 
memory -management systems is the im- 
plementation of the protection at- 
tributes. These may be associated either 
with the logical-address space or with 
the physical memory itself. Associating 
access attributes with the logical seg- 
ment permits a more versatile memory - 
management scheme because different 
users can access the same physical seg- 
ment and have different access attributes 
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associated with their accessing. stored in secondary memory, and the not strictly necessary, such information 

Other information that can be primary memory is not available until can improve the performance of the 

associated with each segment is the segment has been saved. Although overall memory -management system, 
associated not with the protection 

mechanism, but with other functions of ' ' 

the memory -management system. This 

information generally relates to the References 
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Introduction 

The Z8000 and 68000 are similar CPUs, but impor- 
tant differences exist between them. The fol- 
lowing concept papers discuss several substantive 
differences that design engineers should consider 
when trying to choose between these two CPUs. 

Both the Z8000 and 68000 are classified as 16-bit 
CPUs, although each offers many of the attributes 
of a 32-bit CPU; each was designed with provi- 
sions for compatible expansion to a full 32-bit 
architecture. Each of these CPUs has an address 
space two orders of magnitude larger than the 
largest 8-bit CPU. Each has 16 central registers 
designed for general use (see the concept paper on 
the differences in register architecture). Each 
has a powerful instruction set, powerful addres- 
sing modes, and great regularity in the associa- 
tion of instructions with addressing modes. Each 
has a protected "user" mode, privileged instruc- 
tions, and separate system and user stack 
registers. Each has automatic vectoring of traps 
and interrupts, with CPU status saved on a stack. 



Critical Issues 

The following concept papers focus on a number of 
critical design issues. This section summarizes 
the issues discussed and lists the key criteria 
used in addressing the relative merits of the 
Z8000 and 68000 approaches. 



Memory Addressing 

There is a sharp contrast between the segmented 
addressing model of the Z8000 CPU and the purely 
linear addressing model of the 68000 CPU. In 
examining these approaches, the following desira- 
ble attributes for a memory addressing scheme 
should be recalled: 

• An addressing model that mirrors program or- 
ganization 

• Provision for access protection 

• Provision for memory mapping 



• Support for dynamic relocation 

• Support for sharing 

• Support for stacks 



1/0 Addressing 



The Z8000 CPU has separate address spaces for 1/0 
and memory; the 68000 uses memory-mapped 1/0. The 
designer evaluating an 1/0 addressmq mechanism 
should consider: 

• Naturalness of the programming model 

• Protection of 1/0 references 

• Complexity of external interfacing logic 

• Potential for performance improvement 

• Provision for the block 1/0 function 



Address/Data Bus 

The Z8000 and 68000 CPUs use asynchronous 
address/data bus protocols. The Z8000 

time-multiplexes a single set of lines for ad- 
dresses and data, whereas the 68000 uses separate 
lines for addresses and data. In choosing between 
these approaches, the designer must consider: 

• Performance limitations 

• Complexity of interface to peripherals chips 

• Optimal use of CPU pins 



Register Architecture 

The Z8000 and 68000 CPUs are similar in their 
register architectures, but they differ in sig- 
nificant details. Points that should be consi- 
dered are: 

• General vs. special-purpose use of registers 

• Availability of registers of all necessary 
sizes 

• Addressability of subreqisters 

• Extensibility of the register set 
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Operating System Support lowing architectural support features for opera- 
ting systems: 
The Z8000 and 68000 both provide many architec- 
tural features designed to assist in implementing • Restriction of access to CPU and memory 
the "system" portions of large and small appli- • Memory mapping 
cations, but there is a difference in the degree • Sharing of programs and data 
to which this area was addressed in the two de- • Program relocation 
signs. The Z8000 designers gave careful consi- • Stacks 
deration to a thorough, unified approach to ope- • Context switching 
rating system support. As a result, the Z8000 is • I/O system and interrupts 
much stronger in this area than the 68000. The • Distributed control 
discussion of this area covers all of the fol- • Support for conventions 
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The Z8000 and the 68000 take quite different 
approaches to register architecture. The prin- 
cipal points of difference are: 

• General purpose vs. special purpose registers 

• Pairing vs. telescoping of subregisters 
9 Extensibility of the register sets 
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Z8000 and 68000 Registers 



GENERAL PURPOSE VS. SPECIAL PURPOSE REGISTERS 

The Z8000 has a set of 16 16-bit general purpose 
registers. Each can be an address register, a 



data register or an index register. (There are 
restrictions on the use of R0 imposed by the cur- 
rent instruction encoding. ) The 68000 has two 
sets of 32-bit registers: eight address registers 
and eight data registers; either type can be used 
for indexing. 

This difference in register architecture results 
in generally simpler programming of the Z8000 than 
of the 68000. Several aspects of this are: 

• Information in a Z8000 register never has 
to be moved before being used as an address 
or in arithmetic operations. 

• The Z8000 uses the same op codes for argu- 
ments in any of the registers. This is in 
contrast with the 68000' s separate op codes 
(e.g., ADD and ADDA for operations on the 
two register sets). 

• The Z8000 uses the same addressing modes 
for all of the registers. This is in con- 
trast with separate 68000 addressing modes 
like "data register direct" and "address 
register direct." 

The net effect of these differences is that with 
regard to register handling the job of the com- 
piler writer is easier with the Z8000 than with 
the 68000 and that compiled code for the Z8000 is 
likely to be more efficient than code for the 
68000. 

PAIRING VS. TELESCOPING OF SUBREGISTERS 

The Z8000 instructions refer to byte registers, 
16-bit registers, 32-bit registers and (occasion- 
ally) 64-bit registers. The 68000 refers to 
16-bit and 32-bit address registers and to 8-bit, 
16-bit and 32-bit data registers. On both 
machines, every register, except for those of the 
largest size, is contained in a register of the 
next larger size. Thus, every byte register is 
contained within a 32-bit register, and so on. On 
the 68000, this is a one-to-one relationship. 
Each 32-bit register contains exactly one 16-bit 
register, each 16-bit data register contains 
exactly one byte register. In each case, the 
subregister is the rightmost half of the larger 
register. 
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Z8OO0 Register Hierarchy 



On the Z8000 a different scheme is used. The 16 
byte registers are packed into 8 16-bit registers. 
The other eight 16-bit registers contain no byte 
registers. Similarly, the sixteen 16-bit reg- 
isters are packed into the eight 32-bit registers, 
and the eight 32-bit registers are packed into 
four 64-bit registers. 

The 68000 arrangement facilitates the type- 
conversion operations that occur in higher level 
languages, since, for example, an 8-bit value 
stored in the rightmost eight bits of data reg- 
ister zero and sign extended to the whole 32 bits 
can then be referred to as the 32-bit R0, the 
16-bit R0 or the 8-bit R0. On the Z8000, a similar 
situation is possible, but the names would be RRO, 
R1 , RL1 . The price that is paid for this one 
feature is that the 68000 register hierarchy is 
inconvenient to use, while the Z8000 register 
hierarchy is a great programming convenience. For 
example, a Z8000 programmer can allocate four byte 
registers inside of one 32-bit register. On the 
68000 a programmer would have to tie up four 
32-bit registers to store the same four byte 
quantities. That's half of the data register set 
to do what can be done on the Z8000 in one eighth 
of the general purpose register set. If the Z8000 
programmer wishes to use 16 byte registers, this 
can be done using only half of the register set. 
On the 68000, the maximum number of byte registers 
available is eight, and this ties up the entire 
data register set. 

Another advantage of the Z8000 register hierarchy 
is that half of the 16-bit registers and all of 
the 32-bit and 64-bit registers have addressable 
halves. Half of the 32-bit registers and all of 
the 64-bit registers have addressable quarters. 



(R0 



R4 

R5 

R6 

R7 

R8 

R9 

R10 

R11 

R12 

R13 

R14 

R15 



^RQO 



^RQ4 



>RQ8 



>RQ12 



Z8000 General Purpose Registers 

Smaller registers are paired 
to form larger registers. 

Z8O00 Register Hierarchy 



The availability of this feature facilitates many 
programming tasks. On the 68000, there is no way 
to address the left half or any of the three left- 
most quarters of any register. Such op'erations 
must be simulated with shift or rotate instruc- 
tions. 

EXTENSIBILITY OF THE REGISTER SET 

The Z8000 instruction encoding uses 4-bit fields 
to designate registers; the 68000 uses 3-bit 
fields. This means that with no change in op 
codes and no change in instruction format, the 
Z8000 architecture will accommodate expansion of 
the general purpose register set to include 16 of 
each size of register. This means that eight 
32-bit registers and twelve 64-bit registers can 
be added to the register set. The use of 3-bit 
fields and the telescoping of subregisters on the 
68000 preclude a compatible extension of the 
number of registers of any given size and make 
introduction of 64-bit or larger registers 
extremely wasteful of register space. 

SUMMARY 

The Z8000 and 68000 register architectures are 
similar, but there are important differences. The 
68000 uses special purpose address and data reg- 
isters, the Z8000 uses a general purpose register 
file. The Z8000 uses pairing of smaller sized 
registers to make larger sized registers, the 
68000 telescopes subregisters into the rightmost 
portions of larger registers. The Z8000 provides 
for compatible enlargement of the register file, 
the 68000 does not. In each case, the Z8000 
approach is seen to be superior. 
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The Z8000 and 68000 take very different 
approaches to the addressing of 1/0 trans- 
actions. In the 68000, 1/0 addresses and 
memory addresses share the same address 
range. This Is called memory-mapped I/O* 
References to 1/0 addresses are made exactly 
like references to memory addresses, using 
the same Instructions and addressing modes. 
The processor does not know, when it engages 
In a read or write, whether It Is talking to 
memory or to an 1/0 device. 

In the Z8000, there Is a separate address 
range for 1/0 transactions, and separate 
instructions are used. The processor always 
knows which kind of transaction is being 
conducted. The same physical address/data 
lines are used for the two kinds of refer- 
ence; the status lines ST3-STQ distinguish 
between them. 

Several advantages have been claimed for 
memory-mapped 1/0: 

• Regularity - the same instructions and 
addressing modes are available for 1/0 as 
for memory. 

• Simplicity - the size of the Instruction 
set Is reduced, since there are no 1/0 
Instructions. 

• Ease of Implementation - there Is no need 
to design separate 1/0 bus protocols. 

As to regularity, the kinds of operation 
performed on 1/0 ports are limited, as are 
the kinds of addressing that are useful In 
1/0 operations. Furthermore, there are 
special needs of 1/0 operations that are 
different from those of memory operations 
(e.g., block transfers to a fixed address). 

The 68000 design recognizes the fallacy of 
the regularity argument by introducing the 
M0VEP Instruction— a block transfer of the 
bytes of a word or longword to consecutive 
even-addressed or consecutive odd-addressed 
bytes of memory. No 68000 Instruction Is 
provided for block transfers to a fixed 
address In memory. 



The M0VEP Instruction and the missing block 
1/0 Instruction also demolish the simplicity 
argument. Separate Instructions are necessary 
because the two kinds of operation are dif- 
ferent, and If the separation Is not made 
explicit, an additional Instruction will be 
necessary, as was done on the 68000. 

In regard to the ease of Implementation argu- 
ment, 1/0 and memory transactions on the 
Z-Bus are only trivially different (1/0 has 
an added cycle). The difference between the 
Z8000 and the 68000 bus protocols Is not In 
ease of Implementation. The difference Is 
that the 68000 Is locked Into a single bus, 
while the Z8000 has the potential for future 
separation to Improve performance. 

Upon closer Inspection, memory-mapped 1/0 
has, In fact, many disadvantages. 

• It makes protection of 1/0 references Im- 
possible at the Instruction level — 1/0 in- 
structions can't be privileged, because 
there are no 1/0 Instructions. 

• It creates "holes" in the memory address 
space, so that certain addresses— possibly 
localized, but potentially anywhere — 
cannot be used for memory addresses by any 
program. 

• It prevents a compatible separation of 1/0 
and memory buses— blocking an important 
path to performance improvement. 

The question of protection Is Important In 
the design of operating systems. The 1/0 
function Is usual ly control led by the system 
and prohibited to users, so It makes sense to 
make 1/0 Instructions privileged. On the 
68000, there are no 1/0 Instructions (except 
for M0VEP, which Is not privileged), so 1/0 
Instructions cannot be privileged. The only 
way to achieve this kind of protection on the 
68000 Is to assign to an external device the 
job of recognizing 1/0 addresses and prevent- 
ing access to these addresses when the 
processor Is executing in user mode. 
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The problem of "holes" In the memory address 
space can be partially alleviated by placing 
I/O addresses at one end or the other. (The 
68000 sign extension of "short" addresses 
encourages this.) Nonetheless, the addresses 
are missing from the memory address range, 
and a runaway program could Inadvertently 
store Into these addresses, causing unpre- 
dictable results, Including writing to tape 
or disk. 

Finally, since no specific areas of the 
memory address range have been pre-asslgned 
to I/O, the CPU has no way of knowing whether 
the transaction it is conducting Is for I/O 
or memory. As a result, the potential per- 
formance Improvement arising from separation 
of the I/O and memory buses Is forever un- 
available to the 68000. On the other hand, 
in keeping with the philosophy of "economy of 
means"— a major Z8000 design criterion —the 



Z8000 offers both the economy of using one 
bus for both I/O and memory and the potential 
for future separation. 

In summary, the Z8000 design, by recognizing 
the distinction between 1/0 and memory oper- 
ations, has achieved the following advantages 
over the 68000 1/0 architecture: 

• A natural programming model that easily 
incorporates the important block 1/0 
function and avoids awkward Instructions 
like the 68000's M0VEP. 

• Protection — through making 1/0 Instruc- 
tions privileged and through having a 
separate 1/0 address space that no wild 
memory access can reach. 

• Potential for future performance Improve- 
ment through the separation of 1/0 and 
memory buses or through different handling 
of 1/0 and memory transactions, even on 
the same bus. 
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The Z8000 and 68000 address /data buses are similar 
in that both use asynchronous protocols. They 
differ in that the Z8000 time multiplexes one set 
of lines for address and data, while the 68000 
uses two separate sets of lines. The trade-off 
involves the higher potential performance of 
separate, dedicated lines versus the more effec- 
tive use of the limited numbers of pins available 
for chip packages. 

Dedicated lines have a potential for improved 
performance when one device has access to both 
the address and the data and can send them out 
simultaneously. The principal occurrence of this 
situation is a write to memory. There are several 
reasons why this potential advantage is of little 
consequence in a comparison of the Z8000 and the 
68000. 

• Reads from memory (including instruction 
fetches) occur roughly eight times as 
often as writes. A read from memory does 
not benefit from the separation of lines, 
since the address must be sent from the 
CPU to the memory before the memory can 
retrieve the data or instruction in 
question and send it back to the CPU. 

• In the case of writes to memory, most 
memory chips are incapable of simulta- 
neously accepting both the address and 
the data to be stored. 

• Even with a memory chip that is capable 
of accepting addresses and data simul- 
taneously, the 68000 still achieves no 
performance benefit, since 68000 write 
instructions are two cycles longer than 
read instructions (six cycles for writes 
vs. four cycles for reads) in order to 



allow the data bus to be turned around at 
the beginning and at the end of each 
write. 

Considering the other side of this trade-off, the 
use of separate address and data lines results in 
the need for 16 (and, in the future, 32) pins that 
could be utilized to greater advantage. Looking 
just at the CPU, the 68000 faces all of the price, 
power and reliability problems of a 64-pin chip 
with no more capabilities than are provided by the 
Z8000's 48-pin package. When improved manufac- 
turing technology allows economical and reliable 
expansion of the Z8000 to a 64-pin package, the 16 
additional pins will provide greatly increased 
capabilities. 

In addition to the more effective use of CPU pins, 
the multiplexing of address and data lines pro- 
vides a means of addressing directly the internal 
registers of peripheral chips without the need to 
dedicate pins of the peripheral chip to separate 
address lines. Since at least eight data lines 
must generally go to a peripheral chip, these can 
be used during the addressing phase of an instruc- 
tion to address a chip's internal registers (with 
the remaining eight 1/0 address lines possibly 
being decoded by external chip-select logic). 
This simplifiesthe programming of and access to 
peripheral chips by eliminating the separate 
address setup cycle required by an unmultiplexed 
peripheral interface. 

In summary, the use of separate address and data 
lines gains little in performance, especially on 
the 68000 with its extra-long memory write 
instructions. It is wasteful of hard-to-come-by 
CPU pins and encourages a cumbersome interface for 
addressing peripheral chips. 
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INTRODUCTION The Z8000 and the 68000 use fundamentally 

different models for memory addressing. The 
Z8000 uses segmented addressing. The 68000 
uses linear addressing. We shall define these 
terms and explain why segmented addressing Is 
a superior method. 

Segmented addressing Is a "higher- 1 eve I 
language" for memory addressing. That Is, It 
Is a way for the programmer to think about 
and refer to the computer's memory In terms 
that are natural to programming rather than 
In terms of the memory's physical Implementa- 
tion. Linear addressing Is the "machine 
language" of memory addressing. That Is, 
with linear addressing, the programmer uses a 
model for the computer's memory that Is very 
close to Its actual hardware Implementation. 
Before we state more specifically exactly 
what segmented addressing Is and how It 
works, let's look at some of the memory ad- 
dressing tasks that programmers face and see 
what kind of addressing model these tasks 
suggest. 

MEMORY The programmer Is concerned with a variety of 
ADDRESSING programs, data areas, stacks, etc. (for all 
of which the general term "objects" Is used) 
and with the Interactions among these ob- 
jects. What we mean by this Is partly a 
question of how fine-grained our picture Is 
to be. For example, we could say that a pro- 
grammer deals with two objects: the program 
and the data. At the other end of the scale, 
we could say that the programmer deals with a 
multitude of objects— 1 1 sting separately each 
Instruction and datum. Between these alter- 
natives there can usually be found for each 
programming situation a set of largely sepa- 
rate but Interrelated objects. For example, 
for a Chess-playing program, the objects 
might include: 

• Chessboard display program 

• Current position representation 

• Legal move generation program 

• Move evaluation program 

• File of previously evaluated positions 

• Handling routines for previous position 
file 

• Program to study published games 

This program might run under control of an 
operating system that was also divided Into 
objects, Including: 



The traditional approach to dealing with 
these objects Is to allocate portions of the 
computer's memory to each of them. A relo- 
cating loader might pack the programs to- 
gether end to end and then a I locate the data 
areas (of fixed sizes) end to end In the 
portion of memory not occupied by the pro- 
grams. Since the only addressing model 
available with the earliest computers was 
linear addressing, each of the objects would 
receive an address directly related to 
(usually the same as) the actual memory 
address at which It was stored. These ad- 
dresses were all numbers In the range to 
N-l, where N was the total number of memory 
locations available. Every program that 
referred to any of these objects had to do so 
using this address. 
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Figure 1. Traditional Approach to 
Memory Allocation 



• Task scheduler 

• Memory a I locator 

• Secondary storage Interface routines 

• Terminal interaction routines 

• Process status table 

• System stack 

• User process status tables 

The example could be refined and enlarged, 
but these are good examples of what we mean 
by the objects that the programmer must deal 
with. 



PROBLEMS WITH THE TRADITIONAL APPROACH 

This approach always presented problems, and 
as systems grew larger the problems grew 
exponentially. We shall review these prob- 
lems and look at some early solutions. The 
problems can be summarized under the follow- 
ing categories: 

• Inval Id accesses 

• Difficulty of accommodating objects whose 
s i zes vary— 1 1 ke stacks or 1 1 sts 
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• Difficulty of creating and deleting 
objects dynamically — fragmentation of 
memory 

• Difficulty of relocating objects after the 
loader has established linkages among 
them 

• Difficulty of sharing objects among other- 
wise Independent processes 

Invalid Accesses 

The problem of Invalid accesses occurs even 
In the smallest systems and on the smallest 
computers. In Its basic form, the problem 
occurs when a program erroneously uses an 
address as If it belonged to one object when 
It actually belongs to another. For example, 
If an array Is 1024 bytes long and a program 
erroneously refers to Its 1025th byte, then 
the reference will actually be to the first 
byte of the object stored In memory Immedi- 
ately following the 1024-byte array. If the 
erroneous access Is a store operation, then 
the object following the array in memory will 
have been damaged. 
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Figure 3. Allocation of Programs, 
Data and Stack Space 

Identity of the array as arguments and re- 
turns a va 1 1 dated memory address that the 
program can use for fetching or storing. The 
routine might also handle the actual fetching 
or storing, accepting data to be stored as 
another argument or returning the data 
fetched. In either case, the routine would 
va 1 1 date the access by us I ng the array I den- 
tlty as a key to a set of array attributes, 
Including the array's length and location In 
memory. 



Figure 2. A Traditional Invalid Access 

Another example of this problem concerns the 
use of stacks. A common approach to stack 
use In a single-user system Is to allocate 
the "beginning" of memory to programs and 
data and the "end" to a stack, since the push 
and pop Instructions on most computers are 
designed In such a way that stacks grow 
"backwards" In memory; that Is, the first 
Item placed on the stack Is at the highest- 
numbered address, and the "top" of the stack 
Is at the lowest-numbered address. If often 
happens that program changes cause the pro- 
gram and data areas to expand, so that less 
and less remains for the stack. Sooner or 
later, a stack push causes the stack to over- 
flow the allotted area and eradicate the end 
of the area assigned to programs and data. 

A frequently used approach to problems of the 
sort described above Is to create an 
"envelope" around the accesses In question. 
Thus, for example, Instead of using the com- 
puter's Indexing capability to access arrays 
directly, the program might Instead call a 
subroutine that accepts the Index and the 



For the stack example, a similar envelope 
would be placed around pushes and pops. 
Rather than using the machine's push and pop 
Instructions, the program would call sub- 
routines for these operations. Naturally, 
this approach entails a large software over- 
head. 

Another type of invalid access occurs In even 
the most elementary systems, but It presents 
an urgent problem when several programs or 
sets of data— not necessarily related to one 
anothei — share memory simultaneously. This 
problem concerns the restriction of a pro- 
gram's accesses to those portions of the 
memory containing Its bwn subroutines and 
data oi — even more difficult — to portions of 
memory containing data or subroutines that It 
shares with another program and to which It 
is allowed only certain kinds of access (such 
as "read only" or "execute only"). 

The software envelopes discussed above can be 
extended to accommodate shared access to 
data, but It Is difficult to place such 
envelopes around program accesses. Further- 
more, these envelopes are voluntary; that is, 
a programmer who wishes to avoid them can 
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usually discover enough information to be 
able to make the accesses directly. For 
situations of this sort hardware solutions 
were introduced. One such solution was the 
use of limit registers. For example, the 
operating system might set registers that 
defined the limits of the program about to 
run to be locations 10000 through 19999. In 
this case, the program is free to make 
references of any sort so long as the ad- 
dress used lies within the given range. An 
attempt, for example, to call a subroutine at 
address 20000 results in a "trap," and con- 
trol is returned to the operating system. 



and irrelevant to the program using the 
stack. Unfortunately, the way that stacks are 
ordinarily used does not lend itself to this 
approach. Frequently a program is allocated 
a block of stack space, which it then 
accesses using based addressing. That is, 
the actual memory address of the first loca- 
tion of a block of stack space is kept In a 
register, and accesses into the block are 
made by adding an Index (from a register or 
from an Instruction) to the base addresses In 
the register. This common practice is incom- 
patible with the existence of gaps in the set 
of addresses assigned to the stack. 



These examples are an indication of some of 
the ways in which the problem of invalid 
accesses can manifest itself, and they show 
how early system designers attempted to solve 
them. Shortly we shall see how segmentation 
provides a complete solution to this problem. 

Objects of Varying Sizes 

In our stack example above, we saw the kind 
of problem that can arise when an object 
varies in size. We showed how an envelope 
around pushes and pops can detect invalid 
accesses before they occur, but we are still 
faced with the problem of what to do about 
them. In the example given above, there was 
only one stack, and it didn ! t run out of 
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The solution to this problem (before segmen- 
tation was Invented) was to a I locate a larger 
contiguous block of memory to the enlarged 
stack— either by moving the stack to another 
part of memory or by moving something else 
out of its way so that It could be expanded 
where It was. This approach has two Inherent 
problems: the processing overhead to move 
objects around in memory and keep the unused 
memory all in one place and the "relocation" 
problem of changing all of the base addresses 
of blocks of stack space that the program has 
In registers or in storage. The second 
problem Is almost insurmountable, except In 
the most elementary cases. 

The problem of accommodating objects whose 
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Figure 4. Why Stacks Must be in One Piece 



memory until the entire memory of the com- 
puter was exhausted. However, if we had many 
stacks to manage, we might want to assign a 
smal I amount of memory to each and then 
expand those that were about to overflow. If 
a I I accesses to stacks are through the 
envelopes that surround the push and pop 
instruction, this is no problem. The stack 
can merely be "continued" elsewhere In 
memory, and the gap in the actual memory 
addresses between the last location of the 
original stack and the first location of the 
extension will be completely concealed from 



sizes vary has as a special case the problem 
of creating and deleting objects dynamical ly. 
This problem arises In the simplest single- 
user systems— for example, "initialization" 
code might be abandoned after it is executed 
once and the space given to a large data 
array. As with our other examples, however, 
the difficulties mount rapidly as the system 
becomes more complex. In particular, because 
of the difficulty of "relocating" addresses, 
the moving of objects that would be necessary 
In order to keep the unused memory In one 
place Is avoided. The unused memory soon 
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comes to be scattered about In smal I pieces, 
and It becomes Increasingly difficult to find 
contiguous blocks of sufficient size to 
accommodate newly created or expanded 
objects, even when the total amount of unused 
memory Is sufficient. This problem Is known 
as "fragmentation" of memory. 



HARD-TO-USE 
FRAGMENT 




NO CONTIGUOUS 
SPACE AVAILABLE, 
EVEN THOUGH THE 
TOTAL AMOUNT 
AVAILABLE IN 
PIECES IS SUFFICIENT 



Figure 5. Fragmentation 



provided at several levels. 

Dynamic relocation, that Is, relocation that 
occurs after the Initial load of the program, 
requires a mechanism that allows actual ad- 
dresses to be determined at run time. The 
first approach to this Is provided by various 
kinds of based addressing. Based addressing 
of program references Is usually provided by 
PC-relative addressing: cal Is, jumps and 
loads of program constants are specified 
using an offset that Is added to the actual 
program counter value to obtain the memory 
address. Based addressing of data references 
Is also made using offsets— to be added to a 
stack pointer or other address register. 
Relocation effected through based addressing 
Is called "user-controlled" relocation, since 
the setting of the stack pointer or other 
address register Is under control of the 
running program. A better approach from the 
standpoint of reliability Is "system- 
controlled" relocation. This kind of relo- 
cation can be provided using memory mapping. 

Memory mapping Is, In Its simplest form, a 
translation mechanism that converts the ad- 
dresses used by the running program (which 
now become called logical addresses) Into the 
actual memory addresses (now cal led physical 
addresses). With memory mapping, the program 
always uses a fixed set of addresses, and 
relocation Is achieved by a change to the 
translation mechanism. A simple example of 
this Is provided by a mechanism similar to 
based addressing. A value Is set Into a base 
register, and the translation mechanism 
consists of automatically adding that value 
to any address used In the program. (The 
difference between this and based addressing 
Is that with based addressing there Is an 



Traditionally, there has really been no 
solution to this problem other than to leave 
management of the assigned memory to the user 
program. The user Is provided with tools 
like "chaining" commands and overlay struc- 
tures In certain systems, but by and large, 
the creation and deletion of objects Is 
simply treated as part of the "algorithm" 
that the program Implements. Soon we shall 
see how segmentation allows system control of 
this function. 

Relocation 

In discussing the expansion of stacks we 
alluded to the "relocation" problem that 
arose when a stack was moved: a I I of the 
pointers Into It (the base register values 
for accesses to blocks of stack space) become 
Invalid. This Is a special case of the 
general problem of dynamic relocation. After 
the loader has established linkages among the 
parts of the program, It becomes almost 
Impossible to move any of them. This Is 
another problem that had to wait for a hard- 
ware solution. This solution has been 
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explicit reference to the base register In 
the Instruction, With this mechanism, the 
base register is used independently of the 
program to translate the addresses that It 
generates •) 

This very simple form of memory mapping 
quickly evolved In two directions: paging and 
segmentation. Paging Is a natural extension 
of the linear addressing model (although It 
can also be applied to the linear addresses 
used within segments). We won't say any more 
about paging or segmentation at this point. 

Sharing 

A natural outgrowth of memory mapping is a 
mechanism for the sharing of objects among 
otherwise Independent processes. Given a 
mapping mechanism (more sophisticated than 
the simple base register mentioned above) 
that allows different blocks of logical ad- 
dresses to be mapped independently of one 
another, a program or data area In physical 
memory can correspond to different logical 
addresses for different processes. Thus, the 
shared program or data can reside at a con- 
venient location In the logical address space 
of each process, and the mapping mechanism 
will cause references from each process to be 
mapped by that process 1 mapping scheme Into 
the given physical locations. 

We shall say more about memory mapping In 
conjunction with our discussion of segmen- 
tation. At this point, we should simply note 
that system controlled relocation and sharing 
through memory mapping alleviate one of the 
problems that tends to occur with user- 
control led relocation and non-mapped sharing: 
fragmentation of the address space. 



SOLUTIONS 

We have now discussed the major problems with 
the use of the linear addressing model and 
have looked at some early attempts to solve 
them. Now we shall look at the abstract 
addressing model provided by segmentation, 
and we shall see how the Z8000 CPU and memory 
management unit have been designed to work 
together to provide an implementation of this 
model that incorporates memory mapping and 
access protection. We shall show how this 
unified approach alleviates all five of the 
major problems with linear addressing that we 
stated earl ier. 



"name" and a linear address space. The 
"name" Is, of course, a binary number, but we 
call It a name to emphasize the fact that 
there Is no relation between objects Implied 
by a numerical relationship between their 
"names." 

For example, in the example given above, the 
chessboard display program could be assigned 
the name 1, the current position represen- 
tation could be 2, the legal move generation 
program could be 3 and so forth. The address 
of any location within the chessboard display 
program would then consist of the name, 1, 
and an address within object 1's linear 
address space. If this program occupied 2048 
bytes, for example, then the addresses within 
object 1 would be (1,0), (1,1) ... (1,2047). 
One of the attributes of object 1 would be a 
length of 2048 bytes, and the mechanism 
responsible for the interpretation of seg- 
mented addresses would be aware of this 
attribute and would cause an appropriate 
error Indication if an address of the form 
(1,N) with N>2048 were ever used. 

Now consider the case of the current position 
representation— object 2 in our example. 
Let's suppose that this representation takes 
the form of an array of 256 bytes. The 
addresses of these bytes would be (2,0), 
(2,1) ..., (2,255). One means of referring to 
Items of this array Involves the use of 
Indexed addressing. The address of the Item 
referred to would be specified by giving the 
array base address of (2,0) In one place— In 
the Instruction or In a register— and an 
index (also called an offset) In a register. 
The Index is simply a number to be added to 
the second component of the segmented ad- 
dress. Thus, if the Index were 17, then the 
item address would be (2,17). That Is, the 
address manipulation cannot affect the object 
name portion of the address —only the linear 
address within the object is affected. 

Similarly, returning to the display program 
(object 1 In our example), the mechanism 
responsible for address interpretation per- 
forms a slml lar computation for PC-relative 
addressing. If the program contains a branch 
to "current location - 24" or a cal I to 
"current location + 1264" for example, then 
the offset given in the instruction is 
applied to the second part of the. address. 
If the call were made from location (1,562), 
then 1264 would be added to 562, and the 
final address would be (1,1826). 



Segmentation 

Segmentation is the organization of the ad- 
dress space Into a col lection of Independent 
objects. As we noted earlier, in each pro- 
gramming situation there can usually be 
identified a set of largely separate but 
interrelated objects. The segmented address- 
ing model assigns to each of these objects a 



Preventing invalid Accesses 

These examples show how segmented addressing 
helps to alleviate our first major problem 
with linear addressing: Invalid accesses. 
Suppose, for example, that we had made a 
programming error that caused us to address 
the current position representation array by 
using an Index value of 257. With a linear 
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addressing scheme, this would result In a 
reference to the second byte of whatever 
object follows the current position represen- 
tation array In memory. Thus, we might over- 
write the second byte of the legal move 
generation program If that happened to follow 
the array. 

With segmented addressing, the address com- 
putation would result In an address of 
(2,257). The mechanism that Interprets ad- 
dresses would discover that this address Is 
Incompatible with the declared length of the 
array (256 bytes), so an appropriate error 
Indication would be generated. 



ERROR INDICATION 




Figure 7. Attribute Checking for 
Segmented Addressing 

Once the mechanism has been established for 
the checking of accesses against the declared 
size of an object, It Is a small step to add 
the checking of other attributes of objects. 
The problems we mentioned earlier, such as 
protecting one process's data or programs 
from accesses by another process or allowing 
"read only" or "execute only" accesses to a 
section of data or program, can be solved by 
associating attributes with the objects In 
question and checking these attributes 
against properties of the access. A write 
Into a "read-only 11 object, a user access to a 
"system-only" object and other such Invalid 
accesses can be Identified and prevented. 

Sharing and System-Control led Relocation 

Since physical memories do not usually have a 
segmented organization, a segmented address- 
ing scheme must Include a plan for memory 
mapping. As noted earlier, memory mapping 
provides the means of dealing with two of our 



other major problems wlh linear addressing: 
the difficulties of Implementing system- 
controlled relocation and of sharing objects 
among otherwise independent processes. We 
shall see shortly the specific details of how 
this Is accomplished on the Z8000. 

Avoiding Fragmentation 

Our other two major problems had to do with 
the difficulty of creating, deleting, shrink- 
ing or expanding objects dynamically. We saw 
that these operations could lead to fragmen- 
tation In a linear memory space and that 
there were additional problems when stacks 
were Involved. It Is easy to see that seg- 
mentation provides solutions for these prob- 
lems, but rather than discussing them 
abstractly, we shall now look at how segmen- 
tation has been Implemented on the Z8000 and 
how the Z8000 and the MMU work together. 
Then we shall see concretely how all of the 
major problems of linear addressing have been 
solved by segmentation. 



THE Z8001 AND THE MMU 

The Z8000 has been designed with a built-in 
segmented addressing model. Included within 
the 32-blt addresses used by the Z8001 are 
two fields: the segment name field and the 
"offset." The offset Is an address within 
the linear address space of the segment. It 
is cal led an offset because in the Interpre- 
tation of segmented addresses, the offset Is 
added to the physical memory address of the 
"base" of the segment to obtain the physical 
address of the element In question. For 
example, If segment 5 has a base address In 
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physical memory of 1024, then the physical 
memory location addressed by the segmented 
address (5,26) is 1050, because 1024 + 26 = 
1050. 

The Z8001 is designed to work with an ex- 
ternal circuit called a Memory Management 
Unit (MMU), which keeps track of the base 
addresses corresponding to the various seg- 
ments and performs the computation of the 
actual physical addresses. This MMU can also 
associate a variety of attributes with each 
segment and can perform the corresponding 
access checking, generating an error inter- 
rupt (called a "segmentation trap") in the 
event of an invalid access. 

Another feature of this implementation is 
that seven bits have been assigned to the 
segment name field and 16 bits have been 
assigned to the offset. This means that there 
are up to 128 segments, and each of them 
presents a linear address space of 64K bytes. 
Furthermore, the external MMU circuit is 
designed to translate only the uppermost 
eight bits of the offset; the low-order eight 
bits are passed directly to the physical 
memory untranslated. The practical effect of 
this is that a segment base address in physi- 
cal memory must be a multiple of 256 (i.e., 
its low-order eight bits must be zeros), and 
the size of a segment (one of the attributes 
that the MMU checks) must also be a multiple 
of 256 bytes. 

Implementing Structures 
Whose Size Exceeds 64K Bytes 

Let's look at the effect of these implemen- 
tation details on programming the Z8000 and 
on the efficiency of its operation. The most 
obvious effect is that no object can exceed 
64K bytes in size; that is, any data struc- 
ture that exceeds this size must consist of 
more than one segment. This is a genuine 
problem, although it rarely occurs. For- 
tunately, it can be solved through the use of 
software with very little overhead. For 
example, if you are dealing with an array of 
size greater than 64K bytes then you cannot 
use 

LD RL1,RR2(R3) 

to access the byte with index kept in R3 of 
the array whose base is in RR2. Rather, you 
must use a sequence like 



ADD RR2, RR4 
ADDB RH2, RL2 
CLRB RL2 
LD RL1, @RR2 



!add index to base! 

!add overflow to seg name! 

!clear "unused" bits! 



to access the byte with the index kept in RR4 
of the array whose base is in RR2. What you 
are doing in this case is placing several 
segments "end-to-end" and treating the seg- 
ment name I i ke a number. This approach is 
simi lar to "paging." 



Speed of Address Translation with the MMU 

A more positive aspect of the implementation 
details has to do with the computational 
overhead of using an external circuit for 
address translation and attribute checking. 
Two facts enter into this: 

• Since the segment name field is not in- 
volved in the address computations of 
indexed, based or relative addressing, 
this field can be output to the MMU one 
cycle earlier than the offset portion of 
the address, so that the MMU gets a one- 
cycle head start on the address transla- 
tion. 

• The low-order eight bits of the offset, 
which go directly to the memory untrans- 
lated, are the bits needed first by the 
memory, so that the memory also gets a 
smal I head start on the transaction. 

The combination of these two factors results 
in the use of an external MMU circuit that 
entails very little time penalty in memory 
accesses. 

The point made in the previous paragraph 
needs to be stressed: the true independence 
of the segment name field from the offset in 
all address computations means that off-chip 
memory mapping can be achieved with very 
little overhead. This is an architectural 
advantage of the Z8000 that leads to an eco- 
nomical implementation. This can be seen by 
looking at how a nonsegmented CPU might 
achieve memory management. Undoubtedly, the 
approach will be a form of paging. In a 
paged system, the uppermost bits of the 
linear address are treated like a segment 
name field after the address computation is 
complete. Until the computation is complete, 
these bits are treated like part of a mono- 
lithic linear address— they can be changed in 
the course of the computation. Thus, while a 
paging scheme allows memory mapping and 

attribute checking, it suffers from many of 
the problems of linear addressing, and it 
cannot achieve the overlap of MMU and CPU 
computational time that is available with the 
Z8000 because of its true segmentation 
scheme. The only antidote to the computa- 
tional overhead of an off -chip MMU for a 
linear addressed machine is to design an 
on-chip MMU, and with the current technology, 
that approach is likely to lead to a design 
that is short on features. 

MMU Support for Stacks 

One more point worth mentioning about the way 
that the Z8000/MMU combination implements 
segmented addressing concerns the use of 
stacks. Earlier, we noted some of the prob- 
lems that are associated with dynamically 
expanding stack sizes. The most difficult of 
these problems concerned the correction of 
pointers into the stack when a stack was 
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moved to another location to accommodate a 
larger size. Naturally, this problem goes 
away with memory mapping, since the logical 
addresses of the locations already used on 
the stack don't change when it Is physically 
relocated in memory. Furthermore, the MMU 
accepts as one of the attributes of a segment 
that it Is to be used for a stack. This has 
two main consequences: 

• There is a nonfatal stack warning Inter- 
rupt that occurs when the stack is nearly 
full, i.e., when an access Is made Into 
the last 256 words a I located to the 
stack. 

• The memory address computation and size 
specification method are altered to take 
account of the fact that stacks grow down- 
ward In memory from the highest addresses 
toward the lowest. 
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Figure 9. Stack Segments 



CONCLUSION 

This concludes our discussion of the specific 
details of the implementation of segmented 
addressing and memory mapping on the Z8000. 
We have discussed the many problems associ- 
ated with linear addressing, the solution 
provided to these problems by the segmented 
addressing model and the details of segmenta- 
tion on the Z8000. We have shown that seg- 
mented addressing is clearly superior to 
linear addressing. 



Just as there are some who argue that higher 
level languages are "Inefficient" and that 
they don't allow the programmer the total 
flexibility of assembly language programming, 
there are also those who adamantly reject 
segmentation and cling to linear addressing. 
The truth is that there Is merit to their 
argument. Just as higher level languages may 
be inappropriate for very small systems, so 
also may segmentation represent "overkill" in 
a small memory space. The Z8000 answer to 
this problem Is to provide large enough seg- 
ments that small applications can be Imple- 
mented completely within the bounds of one 
segment. The Z8000 CPU Is provided with a 
mode In which addresses consist only of off- 
sets, so that no references occur outside of 
the 64K byte 1 1 near address space of one 
segment. In fact, for applications of that 
size, a smaller package Is provided that does 
not have the eight pins dedicated to the 
segment name output and segment error Inter- 
rupt Input; this smaller version cannot enter 
the segmented mode of operation at all. 

It Is a matter for subjective judgment to 
decide where to draw the lines between sys- 
tems that are too small for segmentation, 
systems in which segmentation Is desirable 
but Inessential, and systems that are so 
large that segmentation Is mandatory. The 
Z8000 architecture provides for a 16-blt 
linear address space but demands segmentation 
for any size above 16 bits. In its 23-bit 
address space, it Is possible that clever, 
well disciplined programmers could manage to 
handle unrestricted linear addressing. In 
Its ultimate 32-bit address space, there Is 
no doubt that segmentation Is the only viable 
approach. 

This concern for the future expansion to 
32-blt address spaces greatly Influenced the 
decision to use segmented addressing In the 
23-blt version. The Z8000 represents a break 
from the architecture of the Z80; ft seems 
short-sighted to ask designers moving from 
8-blt to 16-blt or 23-blt systems to face one 
architectural break today and another In a 
few years. This Is In contrast with the 
situation of designers who adopt the 68000 
today and who will have to face another 
architectural upheaval If true segmentation 
is Introduced — that occurrence seems Inevi- 
table If the address space Increases In size 
to 32 bits. 
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SUMMARY 



The segmented addressing used by the Z8000 Is 
a higher level language for memory address- 
ing. This method Is superior to linear 
addressing, the "machine language" of memory 
addressing, because It provides a model that 
Is natural to programming. 

The traditional approaches to memory a I loca- 
tion based upon the linear addressing model 
cannot solve the following problems: 

• Inval id accesses 

• Accommodating variable-sized objects 

• Fragmentation arising from dynamic crea- 
tion and deletion of objects 



• Dynamic relocation 

• Sharing 

The Z8000/MMU combination provides a seg- 
mented addressing facility that solves the 
above problems and provides the following 
benefits: 

• Built-in segmentation, memory mapping and 
attributes checking 

• Efficient and cost effective operation 

• Support for system-control led relocation 

• Support for stacks, with overflow checking 

• Upward compatibility to 32-bit architec- 
ture 
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One of the most striking differences between the 
architectures of the Z8000 and 68000 is the pro- 
vision for operating system support. This area 
received careful consideration in the Z8000 
design. The designers of the 68000 addressed most 
of their careful attention to other issues. This 
paper shows the importance of operating system 
support features, even in relatively small appli- 
cations, and contrasts the designs of the Z8000 
and the 68000 in regard to operating system sup- 
port. 



OPERATING SYSTEMS 

Every computer application contains an operating 
system — either explicitly or implicitly. For the 
purpose of this paper the following definition of 
an operating system is used: 

The portion (hardware and software) of a 

computer application that is devoted to 

managing hardware and software re- 
sources. 

Most definitions of "operating system" are similar 
to this one. The idea of resource management is 
central to everyone's idea of an operating system. 
The resources of a computer application can be 
divided (approximately) into the following cate- 
gories: 

• Processing elements (e.g., CPUs, floating 
point chips, "intelligent" disk controllers) 

• Storage elements (e.g., ROM, RAM, disks, 
tape) 

• External interfaces (e.g., 1/0 ports, modems) 

• Programs (e.g., compilers, application pro- 
grams) 

A process (also called a task) is the ongoing 
execution of a program by one or more processing 
elements. For example, a compilation is a proc- 
ess. The goals of a computer application can be 
viewed as the completion of processes. From this 
point of view, the job of the operating system is 
to "direct traffic" for as many processes as it 
makes sense to run concurrently, allocating re- 



sources among these processes and resolving con- 
flicts according to an externally selected policy. 
Directing traffic entails: 

• Protection of the operating system and of each 
process from damage or invasion of privacy 
arising from the actions of any other proc- 
ess. 

• Establishment, support, and enforcement, of 
protocols and conventions for the interactions 
of system elements. 

• Facilitation of interprocess communication and 
sharing. 

Thus, the responsibilities of an operating system 
are: 

• Allocation and protection of processing and 
storage elements, external interfaces, and 
programs. 

• Definition, facilitation, and enforcement of 
protocols and conventions. 

• Communication and sharing. 

• Policy enforcement. 

ARCHITECTURAL SUPPORT FOR OPERATING 
SYSTEM RESPONSIBILITIES 

The operating system responsibilities listed above 
differ from system to system. For example, the 
work of a small application may be carried on by a 
single process, although the system process that 
handles external device interrupts will share the 
CPU with the application process. There are 
several kinds of architectural support that facil- 
itate the operating system's task in a wide range 
of applications: 

• Restriction of access to CPU facilities 

• Restriction of memory use 

• Memory mapping 

• Sharing of programs and data 

• Program relocation 

• Stacks 

• Context switching 

• 1/0 system and interrupts 

• Distributed control 

• Support for conventions 
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Each of these features deals with one of the four 
responsibilities listed above--allocat ion and 
protection, protocols and conventions, communica- 
tion and sharing, and policy enforcement. 



Restriction of Access to CPU Facilities 

The operating system must allocate the CPU to a 
process while still protecting itself and other 
processes. That is, the operating system must be 
able to turn the CPU over to a process and be 
assured that the process does not perform poten- 
tially destructive actions. A key to solving this 
problem is some kind of restriction of CPU use. 
Most CPU designs introduce a restricted "user" 
mode, in which certain instructions (called privi- 
leged instructions) cannot be executed and key CPU 
registers (called control registers) cannot be 
accessed. 

The existence of a user mode and privileged in- 
structions does not solve the entire protection 
problem. The other half of the solution involves 
restriction of access to memory and I/O. In addi- 
tion, the introduction of user mode brings another 
problem, namely the question of how the CPU passes 
between system and user modes (especially, how it 
gets out of user mode). A solution frequently 
provided is one or more System Call instructions. 
These instructions allow programs running in user 
mode to call system mode programs without allowing 
the user mode program to retain control of the CPU 
once it has left user mode. 



Restriction of Memory Use 

Most CPU designs call for some sort of comprehen- 
sive memory management facility, which provides a 
unified approach to restriction of memory use, 
memory mapping, program relocation, sharing of 
programs and data, and stack use. 

Restriction of access to memory usually depends 
upon the use of sets of attributes associated with 
portions of the memory address range of the CPU. 
These attributes are checked against certain 
access rights associated (implicitly or explicit- 
ly) with each process. Then, for example, if a 
program in user mode attempts to access a memory 
address whose attributes don't match the program's 
access rights, the CPU will trap to a system rou- 
tine designed to deal with such invalid accesses. 

The portions of the memory address range to which 
sets of attributes can be assigned depend upon the 
CPU addressing scheme and the memory management 
facility. Typically, in a machine using two- 
dimensional (segmented) addressing, attributes are 
associated with a segment. In a machine with 
linear addressing, attributes are usually associ- 
ated with fixed-size blocks of addresses called 
pages. (See the Z8000 vs. 68000 concept paper, 
"Segmented vs. Linear Addressing.") 



Memory Mapping 

As noted above, the operating system allocates 
memory and programs and facilitates sharing and 
interprocess communication. These tasks are aided 
by memory mapping. 

Memory mappinq is the establishment of a function 
that assigns to each address (now called a logical 
address) in the memory address range an address in 
the actual physical memory available to the appli- 
cation. Naturally, a completely arbitrary function 
would be difficult to specify and to alter, so the 
usual approach is to divide the logical address 
space into blocks of contiguous addresses and to 
map each block to a block of contiguous physical 
addresses. All that is required to specify such a 
mapping is to provide the base physical address 
for each of these blocks and, if not predetermined 
by the architecture, to provide the origins or 
sizes of the blocks of logical addresses. 

In general, the blocks of logical addresses that 
can be mapped separately are the same as the 
blocks of memory that can be assigned attributes. 
The information about block size, base physical 
address, and attributes is usually grouped 
together into a segment or page descriptor. 



Sharing of Programs and Data 

Given memory mapping and access restriction, it is 
easy to see how the operating system can facili- 
tate the sharing of programs and data among proc- 
esses while still providing protection. For 
example, a block of physical memory containing a 
generally useful program can be "placed in the 
maps" of several processes. That is, each process 
can have a block of logical addresses (not neces- 
sarily the same addresses if the program is relo- 
catable) that is mapped into the given block of 
physical memory. Similarly, a block of data can 
also be placed in the maps of several processes. 

In the above examples of sharing, protection is 
provided by the access restriction mechanism dis- 
cussed earlier. In the case of a program, for 
example, one of the attributes of the associated 
block of logical addresses can be that it is read 
only or even execute only. [This requires the 
existence of instructions and addressing modes 
that allow the generation of pure (i.e., not 
self-modifying) code.] Furthermore, the attri- 
butes can change, depending upon which process is 
running. For example, when the process respon- 
sible for a given block of data is running, the 
attributes of the associated block of logical 
addresses can be unrestricted, and when other 
processes are running, the attributes can include 
read only. The changing of attributes discussed 
here is part of the context switching accompanying 
the transfer of the CPU from one process to 
another. (In a multi-CPU system, the protection 
has to be provided by a difference in the access 
rights of the processes, not by a change in attri- 
butes. ) 
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Program Relocation 

There are three types of relocation: static 
relocation, dynamic logical address relocation, 
and dynamic physical address relocation. Static 
relocation is the kind provided by a relocating 
loader. Separate source files are assembled as if 
each were to begin at logical address zero, and a 
program combines these separate files into one 
large program designed to be run at fixed logical 
addresses. Dynamic logical address relocation is 
the process of changing the logical addresses at 
which a given program is to run. In most cases, 
this is possible only if the program has been 
designed to be independent of the logical 
addresses at which it runs. Dynamic physical 
address relocation is the process of changing the 
physical addresses at which a given program is to 
run, while leaving its logical addresses 
unchanged. By definition, dynamic physical 
address relocation makes sense only in connection 
with memory mapping. 

Static relocation is possible regardless of the 
CPU architecture, whereas both kinds of dynamic 
relocation depend upon architectural support 
features. Both kinds of dynamic relocation help 
the operating system meet its responsibilities: 
Logical address relocation, as noted above, is 
important in program sharing, because it allows 
the logical address spaces of the processes shar- 
ing a given program to be managed independently. 
Physical address relocation is important in the 
allocation of memory, because it allows "garbage 
collection" to be performed easily and facilitates 
the implementation of virtual memory schemes. 



Dynamic Logical Relocation. Dynamic logical relo- 
cation depends upon the ability to write programs 
that are independent of the logical addresses at 
which the program's instructions reside. Most 
CPUs provide some support for such programs. To 
understand this support, we must first understand 
what computer instructions do. 

The CPU interprets instructions that are stored in 
memory. Each instruction must specify (explicitly 
or implicitly): 

• The operation to be performed. 

• The locations of the arguments. 

• The location of the next instruction to be 
executed. 

Computers have been designed (e.g., the IBM 650) 
in which all of these addresses are specified 
explicitly in each instruction. Obviously, no 
program on such a computer can be independent of 
the addresses at which the instructions reside. 
On most computers, however, position-independent 
means are available for specifying the locations 
of arguments and the sequence of instruction exe- 
cution. These means all rely upon the use of 
registers and special addressing modes. The most 
fundamental of these registers is the Program 
Counter (PC), which is found in all modern com- 



puters; the associated addressing mode is called 
PC-Relative (or simply Relative) Addressing. 

The PC contains the address of the next instruc- 
tion to be executed. As each instruction is 
fetched from memory, the PC is changed to contain 
the address of the first memory location following 
the fetched instruction. Thus, in most cases, the 
sequence of instruction execution is defined by 
the sequence in which the instructions are stored 
in memory. This leaves only the case of trans fer- 
of -control instructions (i.e., instructions that 
change the value of the PC) to be considered. 
Most modern computers have transfer instructions 
that add a signed offset (usually contained in the 
instruction) to the PC value. That is, these 
transfer instructions use relative addressing. 

Obviously, transfer instructions that use relative 
addressing can be represented independently of the 
addresses at which the program containing the 
instructions resides. Other position-independent 
means of changing the PC are available on many 
computers: 

• Indirect Register Addressing — the PC is set to 
a value specified in a register. 

• Based addressing — the PC is set to the sum of 
an address value specified in a register and 
an offset specified in the instruction or in a 
register. (Many variations of based addressing 
exist.) 

• Popping from a stack — the PC is set to a value 
previously saved on a stack. 

Position-independent argument specification is 
achieved similarly. Based addressing, stacks, 
register addressing (the analog for argument spec- 
ification of Indirect Register mode for trans- 
fers), and even Relative Addressing (for program 
constants) are commonly used ways of specifying 
arguments, which are available on many computers. 



Dynamic Physical Relocation. Changing the physi- 
cal addresses at which a program resides without 
changing the logical addresses is only possible 
with a memory-mapping scheme. Given memory- 
mapping, this kind of relocation requires no 
further architectural support. 

Physical relocation is helpful to an operating 
system that must allocate a limited amount of 
memory among a varying set of processes or among 
processes with varying memory needs. It helps 
avoid the fragmentation of memory that can occur 
when there is dynamic allocation and release of 
varying amounts of memory. Physical relocation is 
also the basis of any virtual memory system. 

A virtual memory system is an addressing scheme in 
which the logical address space is larger than the 
physical memory. Parts of the logical address 
space correspond to blocks of secondary storage, 
which are brought into physical memory only when a 
program attempts to access them. A virtual memory 
system requires extensive CPU support, since it 
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involves, in effect, the transfer of information 
to or from secondary storage in the midst of exe- 
cuting an instruction. 

Stacks 

Stacks are an important tool for meeting the oper- 
ating system's responsibilities. A stack is a 
variably sized last in, first out memory. Associ- 
ated with a stack are two operations, pushing 
(adding an item) and popping (removing an item). 



Stacks are used by the operating system (explicit- 
ly or implicitly) to allocate memory in a flexible 
way that, in connection with based addressing, 
allows programs that need nonregister storage to 
remain position independent. Special cases of this 
are the storage of return addresses for subroutine 
calls and machine state for interrupt processing. 

Stacks provide an important application of dynamic 
physical relocation, because the way they are used 
makes logical relocation of stacks almost impos- 
sible. In order to provide flexible allocation of 
stack space, the operating system must be able 
to expand a stack upon demand. This sometimes 
entails physical relocation of the stack to a lar- 
ger area of physical memory, since with based 
addressing, a stack must consist of contiguous 
logical addresses and since most memory -map ping 
schemes require contiguous logical address blocks 
(below a minimum size) to map into contiguous 
physical addresses. 

Other architectural features desirable for stack 
support include: 

• The ability to designate one or more stacks 
for program use. 

• Single- and multiple-argument push and pop 
instructions. 

• The ability to address items at locations 
defined relative to the top of a stack. 

• Automatic warning (traps) of impending stack 
overflow or underflow. 

Most architectures call for the implementation of 
stacks as linear arrays in memory with an address 
register marking the top of the stack and provid- 
ing (through based addressing) access to items at 
other locations in the stack. The stack register 
is a dedicated (special -purpose) register in some 
architectures. In other architectures, any ad- 
dress register can be used as a stack register, 
although the program usually cannot specify which 
stack register is to be used for saving returns 
from a subroutine or the machine state on inter- 
rupts. 

The implementation of stacks as arrays in memory 
and the use of general-purpose address registers 
for stack registers make the provision of overflow 
and underflow protection difficult. Architectures 
that provide stack limit protection usually do so 
through the use of the attribute specification 
associated with memory protection. Several archi- 



tectures provide stack access protection by means 
of a rudimentary separation of stack and data ad- 
dress spaces through externally interpreted CPU 
status outputs. A better approach is provided by 
a two-dimensional (segmented) addressing scheme, 
in which distinct objects and not just stacks can 
be assigned to independent parts of the address 
space. (See "Segmented vs. Linear Addressing," 
Z8000 vs. 68000 Concept Paper.) 

Context Switching 

One of the difficulties of running several proc- 
esses concurrently is the overhead associated 
with context switching. The context of a process 
is the portion of its state that occupies shared 
resources. For example, since most CPU architec- 
tures call for only a single Program Counter (PC), 
all processes must share this register, so the PC 
value of each process is part of its context. Most 
architectures also call for a single set of 
general-purpose registers, control registers, CPU 
status registers, and so forth. Thus, when the 
same CPU is allocated to more than one process, 
the process contexts must include the contents of 
any of these registers used by the processes. 

Context switching is the saving of the context of 
one process and the recalling of the stored con- 
text of another process. Some architectural 
features for the support of context switching are 
desirable. These include automatic saving of CPU 
state on interrupts, single-instruction block 
register saving and restoring, and access to all 
necessary control registers. 

All modern CPUs provide automatic saving of a 
portion of the CPU state on interrupts and access 
to all control registers that can form part of a 
process context. Block saving and restoring of 
registers is available with some CPUs. Either a 
starting register and the number of registers to 
be saved or a bit-encoded selection of registers 
to be saved provides some f lexibility--not all 
registers need to be saved in every case. In most 
cases, the operating system saves registers on a 
stack. 



I/O System and Interrupts 

The operating system responsibilities pertaining 
to the I/O system and interrupts vary greatly with 
the type of application. The architecture of a 
general -purpose CPU must provide the flexibility 
necessary to accommodate the I/O requirements of a 
wide range of application types. 

One of the operating system's most difficult tasks 
in this area is the control of access to I/O 
resources. Unlike memory, which can be divided 
into large, relatively homogeneous blocks, the 
elements of the I/O space require special -purpose 
management, protection, and access techniques. In 
addition, device timing requirements and exter- 
nally set policies for conflict resolution make 
hardware support of I/O mechanisms mandatory. 
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Desirable architectural features for the support 
of the I/O system and interrupts include: 

• A vectored interrupt scheme. 

• Program-controlled specification of the CPU 
state to be established for each type of in- 
terrupt. 

• A rapid, automatic context-switching mechanism 
for responding to interrupts. 

• A means of defining conflict-resolution 
policies and "interruptibility" of interrupt 
processing. 

• Block I/O instructions and DMA capabilities. 

• Restricted access to I/O facilities. 

A vectored interrupt scheme allows the CPU state 
to be switched immediately to an appropriate proc- 
essing routine without the need for software to 
ascertain the interrupt type and call the appro- 
priate routine. The port of connection or the 
contents of a vector supplied by the interrupting 
device are used to determine the new state. 

A vectored interrupt scheme can be designed so 
that the new CPU state is specified in the hard- 
ware by the interrupting device, but in most 
architectures this is under program control. 
Most CPUs store this information in memory loca- 
tions (often called interrupt vectors). In some 
CPUs a fixed block of addresses is devoted to 
storage of interrupt vectors, but a better ap- 
proach is to allow any block of locations to serve 
and to have a CPU control register that points at 
the chosen block. One advantage of this approach 
is that the block of vectors can be assembled with 
the program and need not be set individually by 
initialization instructions. One disadvantage is 
that it discourages modular management of the 
vectors. 

Every CPU with an interrupt facility has some kind 
of context-switching mechanism to support it, 
usually involving the use of a stack. In CPUs 
that support multiple stacks, the architecture 
designates one of these stacks for this use. 
Those parts of the machine state that the inter- 
rupt processing routine cannot easily save by 
itself are pushed onto the designated stack. This 
saved information must include the PC value, and 
it can include other items as well. Usually, CPU 
condition indicators and operating mode bits are 
saved, while general -purpose register contents are 
not. Such CPUs have interrupt return instructions 
to pop the saved CPU state off the stack, thus 
returning the CPU to its pre-interrupt state. 



Block I/O instructions and direct memory access 
(DMA) capabilities are important features that 
improve performance. Block I/O instructions re- 
quire careful implementation. In general, they 
must use general -purpose registers to save their 
ongoing state, so that they can be interrupted. 
DMA capabilities require the development of bus 
control protocols and a means of protecting par- 
tially loaded or saved memory blocks from unwanted 
access by concurrently executing programs. 

Restriction of access to I/O facilities can take 
many forms. In a CPU with a user operating mode 
and privileged instructions, the I/O instructions 
can be privileged. This is the easiest and most 
natural approach. In a CPU that does not have I/O 
instructions and a separate I/O address space (see 
Z8000 vs. 68000 concept paper, "Memory Mapped vs. 
Explicit I/O"), a memory-protection approach must 
be taken. 



Distributed Control 

One of the recent advances in operating system 
design is the distribution of operating system 
functions among many separate processes. Such 
distributed systems present problems of inter- 
process synchronization. 

When processes to which separate processing units 
may have been allocated share a common memory, the 
techniques of guarded commands and semaphores 
(developed by Dijkstra and others) are applicable. 
The basic architectural support for these tech- 
niques is the atomic Test and Set instruction, a 
CPU instruction that tests a memory location for 
the value "available" and simultaneously sets the 
value to "not available." The word "atomic" means 
that there can be no other access to the given 
memory location between the "test" and "set" por- 
tions of the instruction, so no two concurrently 
running processes can find the location set to 
"available" simultaneously. Implemention of a 
Test and Set instruction requires a bus-locking 
mechanism. 

When processes do not share a common memory, a 
similar nonmemory exclusion mechanism must be 
provided. A separate bus can carry the signals 
needed to implement such a mechanism, and CPU 
instructions can be provided to manage the CPU's 
connection to that bus. 



Support for Conventions 



Conflict resolution is controlled by a policy that 
is set by the system designer and enforced by the 
system. The usual approach is to provide a small 
number of priority levels to which device inter- 
rupts can be assigned, by virtue of either the 
means of connection to the CPU or the setting of a 
priority level in the "vector" for each device. 
Then, when the CPU is processing a device inter- 
rupt of a given priority level, only higher-level 
interrupts can occur. 



One of the issues that must be considered in the 
design of a CPU is whether its architecture should 
support all conventions equally, favoring none, or 
whether it should encourage, through special fea- 
tures, specific conventions. For example, should a 
CPU be designed with general support for high- 
level languages, or should it be designed to op- 
timize Pascal, say, at the expense of making 
FORTRAN programming less efficient? Should it 
provide special features that make a subroutine 
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argument passing convention using the stack 
especially efficient at the cost of decreased 
efficiency for other argument passinq conventions? 

In practice, there are many cases in which the 
choice to support one method of accomplishing a 
task makes the designer's job easier, but dis- 
courages the use of other, equally valid approach- 
es. If the other approaches are no better than 
the one supported, then support of one specific 
approach is a net advantage. But if the unsup- 
ported approach is preferable to the supported one 
in some applications, and if the special support 
feature makes the unsupported feature less effi- 
cient than it would otherwise have been, then 
there is a net disadvantage for those applica- 
tions. 

Another aspect of the system's support for con- 
ventions is the definition of the CPU's operating 
environment provided by a coherently designed 
family of components and a compatible interconnect 
bus. In most CPU architectures, this definition of 
the CPU's operating environment is not given much 
attention. Key points that should be considered 
are: 

• The need for a staged, modular development — 
over many years — of a CPU and its component 
family. 

• The importance of changing the distribution of 
function between the CPU and associated com- 
ponents with minimal impact on existing pro- 
grams. 

• The need for future enlargement of capabili- 
ties without substantial redesign of existing 
components or systems. 



THE Z8000 APPROACH 

The Z8000 designers were aware of all of the oper- 
ating system support features mentioned in the 
preceding section, and an attempt was made to 
provide for these support features in the Z8000 
architecture. Naturally, other design criteria 
were present and tradeoffs were made, but on the 
whole, a better and more unified approach to 
operating system support was taken with the Z8000 
than with other CPUs in its class. 



Restriction of CPU Use in the Z8000 

The Z8000 has a system/normal bit in its Flag/ 
Control Word register (FCW). When the bit is in 
the normal state, privileged instructions cannot 
be executed. Operating system tasks are expected 
to execute in the system mode. The privileged 
Z8000 instructions are: 

• I/O instructions, including the interrupt 
return and nonmemory synchronization instruc- 
tions. 

• Control register manipulation instructions. 

• The Halt instruction. 



In addition to privileged instructions, another 
protection feature is associated with the system/ 
normal bit. There are two copies of the implied 
stack reqister (the stack reqister used for inter- 
rupt and subroutine returns); one is used when the 
CPU is in system mode, the other when it is in 
normal mode. Programs executing in normal mode 
have no access to the system mode stack register. 

Passing between system and normal modes requires a 
change to the FCW. This can only be accomplished 
through a privileged instruction (LDCTL, IRET, 
LDPS) or automatically in response to an interrupt 
or trap. A system call trap (a one-word instruc- 
tion with eight programmable bits) allows a normal 
mode program to call one of 256 system mode pro- 
grams. 



Memory Management in the Z8000 

The Z8000 design provides for a comprehensive 
memory management facility, which offers a unified 
approach to restriction of memory use, memory map- 
ping, sharing of programs and data, program relo- 
cation, and stack use. This memory management 
facility is integrated with a segmented (two- 
dimensional) addressing scheme in the CPU. (For a 
discussion of this entire area, see the Z8000 vs. 
68000 concept paper, "Segmented vs. Linear Ad- 
dressing.") One of the many advantages of segmen- 
tation is that it is an ideal organization for a 
system (e.g., UNIX*) in which there are many small 
tasks. 

Another feature of the Z8000 memory management 
facility is that it is designed to facilitate the 
implementation of virtual memory systems. Virtual 
memory is an important technique for handling the 
enormous address space of a CPU like the Z8000 
with a reasonable amount of physical memory. 
Details of the implementation of Z8000 virtual 
memory systems are available in the articles on 
the Z8003/Z8004 by Calahan, Patel, and Stevenson 
and on the PMMU by Hu, Lai, and Stevenson (both to 
appear in "Electronics" in late summer 1981). 



Context Switching in the Z8000 

Z8000 interrupt and trap-handling provides an 
automatic, rapid context switch from the executing 
program to the interrupt-processing routine. The 
FCW and PC values and a "reason" are saved on the 
system mode stack, and new FCW and PC values are 
set from the program status area (PSA) entry cor- 
responding to the interrupt type. 

The Z8000 block register saving and restoring 
instructions facilitate context switching. These 
instructions can be used to simulate the pushing 
or popping of a block of registers to or from any 
stack. 



* UNIX is a registered trademark of Bell Labora- 
tories. 
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In some cases, the values of control registers are 
essential to the context of a process. (The 
normal stack register and the FLAGS register are 
obvious examples.) A load control register in- 
struction allows the transfer of any of these 
registers to or from a general -purpose register, 
so they can be saved and restored like other reg- 
isters. 



The Z8000 Component Family and the Z-BUS 

A fundamental concept in the Z8000 architecture is 
that of a family of components designed to work 
together. Because a CPU and its associated com- 
ponent family must be developed and introduced 
over a span of several years, the outlines of the 
family and the framework to support it must be 
established at the outset. In the case of the 
Z8000, the CPU chip was designed with many hooks 
in place, including segmented memory addressing, 
nonmemory synchronization instructions, block I/O 
instructions, a multiplexed address/data bus, an 
encoded 4-bit CPU status output, and extended pro- 
cessor instructions. The extended processor in- 
structions are an especially good example of this 
planning. Processor instructions and a bus proto- 
col allow for the development of "slave" proces- 
sors (like a floating-point chip) that execute 
instructions taken from the CPU's instruction 
stream and have access to the CPU's addressing 
capabilities. 

The ZCI M Z-BUS Component Interconnect provides 
the signal lines and protocols required to tie 
members of the Z8000 family together and provides 

he necessary interface specification for family 

embers still to be develoDed. 



the necessary interface specir 
members still to be developed. 

An even wider environment for the CPU is defined 
by the ZBI™ Z-BUS Backplane Interconnect, which 
is compatible with the ZCI and provides for expan- 
sion of the Z8000 to a full 32-bit architecture. 



so that interrupts are not processed until the un- 
masking of the associated line. When interrupts 
arrive on more than one line simultaneously, the 
priority determines which is processed first. The 
processing routine for any interrupt type can be 
interrupted by the routine for any other if the 
corresponding line has not been masked. Whether 
other lines are to be masked or not can be deter- 
mined automatically by specifying the appropriate 
mask bit in the FCW portion of the PSA entry. 
Otherwise, the determination can be made by the 
program, which can bracket sensitive code between 
Disable Interrupt (DI) and Enable Interrupt (EI) 
instructions. 

A daisy chain is used to determine the order of 
processing of interrupts from devices attached to 
the CPU on the same interrupt line. In this way, 
devices closer to the CPU can interrupt the proc- 
essing of interrupts from devices farther away 
from the CPU, unless the given line is masked 
during all or part of the processing. 

A key aspect of the Z8000 I/O system is the pro- 
tection provided by privileged instructions. This 
protection allows an operating system to manage 
the I/O interfaces without interference from 
normal mode programs. 



Distributed Control 



The Z8000 architecture provides ways to synchron- 
ize processes that share memory and those that do 
not. The Test and Set instruction provides the 
basis for synchronization of processes that share 
memory. For nonmemory synchronization, the Z-BUS 
has a set of lines and a protocol for resolving 
simultaneous requests for shared resources, and 
the CPU provides instructions to support the bus 
connection and protocol. 



The Z8000 I/O System and Interrupts 

The Z8000 uses a block of memory called the pro- 
gram status area (PSA) to store interrupt vectors 
(i.e., the new CPU status) for each type of inter- 
rupt and trap. In addition to separate lines for 
nonvectored and vectored interrupts and a non- 
maskable interrupt for situations that can't wait, 
there is a table of PC values to be indexed by an 
8-bit vector placed on the address/data bus by the 
interrupting device. The block of memory used for 
the PSA is not fixed, as with some CPUs; it can be 
anywhere in memory, and a pointer to it (the PSAP 
register) can be set using the privileged LDCTL 
instruction. 

Conflict resolution is done simply. The three 
kinds of interrupt (nonmaskable, nonvectored, and 
vectored) are assigned three levels of priority by 
the CPU. In addition, the vectored and nonvec- 
tored interrupt lines can be masked (using the 
privileged Disable/Enable Interrupt instruction), 



Support for Conventions 

The Z8000 design supports many conventions. Prin- 
cipal among these are 

• Use of a segmented address scheme. 

• Use of message passing for interprocess com- 
munication. 

• Component and backplane bus protocols. 

• Interrupt protocols for all components. 

The only convention listed above that has not yet 
been discussed is message passing. A message is a 
set of characters sent by one process and 
received, asynchronously, by another. The proc- 
esses do not need to know whether they have been 
allocated the same or different processing ele- 
ments. 

The Z8000 family architecture provides message 
passing support both in the CPU and in other com- 
ponents: 
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• Block I/O instructions in the Z8000 CPU sup- 
port message passing. 

• The Z-FIO (FIFO I/O unit) chip provides the 
asynchronous interprocessor connection neces- 
sary to a message-passing philosophy. 

• The Z-UPC (Universal Peripheral Controller) 
chip accepts commands from and delivers mes- 
sages to the master CPU in designated message 
registers in the Z-UPC. 

• The DMA (Direct Memory Access) chip has been 
designed with a "flyby" mode that allows ex- 
ternal devices (e.g., a Z-FIO chip) high-speed 
direct access to memory without storage of the 
data by the DMA chip. 

THE 68000 APPROACH 

The 68000 provides many of the architectural sup- 
port features mentioned earlier, but there are 
several that did not receive the same careful 
attention given to the Z8000 design. 

Restriction of CPU Use in the 68000 

The 68000 has system and user modes and privileged 
instructions, just like the Z8000. The two mam 
differences are: 



needs of most applications. The 68000 's 16 calls 
will be too few for all but the simplest cases, so 
most 68000 applications will be unable to use the 
system and user modes in a natural way. 

Memory Management in the 68000 

The key point to understand about the 68000 memory 
management mechanism is that it is completely 
external to the CPU. Several facts follow from 
this: 

• The 68000 cannot use segmentation without 
extensive software overhead. 

• Because of the overhead that a fully general 
mapping facility would entail, the 68000 must 
use a "simple but powerful" scheme that limits 
mapping to the bitwise replacement of fields 
in the address. 

Naturally, many benefits can be derived from the 
use of such a scheme, but it can never be more 
than a separate, after-the-fact transformation and 
checking mechanism, so that the 68000 is not re- 
lieved of the problems of linear addressing. (See 
the Z8000 vs. 68000 Concept Paper "Segmented vs. 
Linear Addressing".) 



• In the Z8000 1/0 instructions are privileged, 
while in the 68000 ordinary memory reference 
instructions double as 1/0 instructions and 
thus cannot be privileged. 

• The Z8000 has one System Call (SC) instruction 
with 8 programmable bits, while the 68000 has 
16 separate System Call instructions, none of 
which has any programmable bits. 

The 68000 operating system designer is forced to 
use an external memory management system to imple- 
ment the protection of 1/0 operations. The Z8000 
operating system designer can work with privileged 
instructions--a tool that is consistent with the 
tools used for protection of other key Z8000 func- 
tions. (For a detailed discussion see the Z8000 
vs. 68000 concept paper "Memory-Mapped vs. 
Explicit 1/0.) 

The second point boils down to the number of dis- 
tinct instructions available for system calls and 
the number of separate traps over which these 
instructions are distributed. The 68000 architec- 
ture provides for a total of 16 system calls and 
ties them all to separate traps. The Z8000 archi- 
tecture provides for 256 system calls and ties 
them all to one trap, so that dispatch software is 
reguired to route the calls to the proper rou- 
tines, but obviously, the Z8000 design can accom- 
modate the addition of a hardware dispatch 
mechanism in the future with no change to user 
programs. Furthermore, the 68000 approach forces 
duplication of context-saving operations (e.g., 
register saving). 

The key difference is that the Z8000 has 256 
System Call instructions, while the 68000 has only 
16. The Z8000's 256 calls will accommodate the 



Context Switching in the 68000 

There is very little difference between the Z8000 
and the 68000 in their approaches to context 
switching. 



The 68000 Component Family and Bus 

The idea of a family of components designed to 
work together, which is so fundamental to the 
Z8000 philosophy, is not clearly evident in the 
68000 design. While the Z-BUS forms the framework 
for the entire, expanding Z8000 Family, the 68000 
seems to have been designed with an eye toward 
compatibility with the older 6800 family periph- 
erals and with existing bus structures. 

While the Z8000 is designed to include features to 
facilitate its integration into a family of com- 
ponents, the 68000 seems to have been designed 
before there was a clear conception of what its 
environment would be. For example, the Z8000 has 
provision for memory management integrated into 
the CPU; the 68000 memory management mechanism is 
entirely external to the CPU. The Z8000 has a 
nonmemory synchronization facility; no bus or 
processor provision for nonmemory synchronization 
exists in the 68000. The Z8000 was designed with 
a multiplexed address/data bus to accommodate the 
advanced programmable peripherals designed with 
it; the 68000 was designed with a nonmultiplexed 
address/bus (See the Z8000 vs. 68000 Concept 
Paper "Multiplexed vs. Non-Multiplexed Address/ 
Data Bus"). The Z8000 was designed with block 1/0 
instructions to facilitate the message passing 
protocols to be used with the Universal Peripheral 
Controller and, via the FIFO interface, with other 
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processors and devices; the 68000 does not seem to 
support any particular interprocess communication 
protocols and techniques. 

These examples only serve to emphasize the key 
point: the Z8000 design is based on a family 
concept, the 68000 design is not. 



The 68000 1/0 Systen and Interrupts 

The Z8000 and 68000 interrupt systems are similar, 
with roughly equivalent capabilities. Notable 
differences are: 

• Location of the interrupt vectors. In the 
Z8000, the PSA can be anywhere in program 
memory. In the 68000, the interrupt vectors 
must be specific locations in data memory. 

• Resolution of priority. The 68000 requires 
each device to supply a 3-bit interrupt re- 
quest code that is used in determining the 
device's priority. In the Z8000 Family, 
devices can be used at any priority level 
without modification. Each device is attached 
to one of three interrupt request lines, and 
each line has a different priority. A daisy- 
chain protocol defines priorities among 
devices attached to the same line. 

A key difference between the Z8000 and 68000 1/0 
systems is the use of explicit 1/0 instructions in 
the Z8000 and the use of memory mapped 1/0 in the 
68000. (See the Z8000 vs. 68000 Concept Paper 
"Memory Mapped vs. Explicit I/O".) Among other 
problems, this forces the 68000 to use the coarse- 
grained protection of memory management to do what 
the Z8000 accomplishes with privileged 1/0 in- 
structions. 



Distributed Control 

The 68000, like the Z8000, has a Test and Set 
instruction for synchronizing processes that share 
memory. The 68000 lacks a mechanism for nonmemory 
synchronization such as is provided by bus proto- 
cols and CPU instructions on the Z8000. 



Support for Conventions 

The only area in which the 68000 provides support 
for an operating system's definition of conven- 
tions is subroutine argument passing. By means of 
its Link and Unlink instructions and its stack- 
oriented addressing modes, the 68000 design en- 



courages a stack-based argument-passing scheme. 
While the Z8000 also allows an efficient stack- 
based argument -passing convention, it provides 
equally good support for a register-based conven- 
tion. 

In the areas of memory addressing, component and 
backplane bus protocols and interprocess communi- 
cation, the 68000 provides little support for the 
framework of conventions that an operating system 
must provide. Especially striking is the contrast 
between the Z8000's system-wide support of message 
passing for interprocess communication and the 
68000's failure to provide any special support for 
interprocess communication. 

SUMMARY 

Operating systems are responsible for the alloca- 
tion and protection of processing and storage 
elements, external interfaces and programs; for 
the definition, facilitation and enforcement of 
protocols and conventions; for communication and 
sharing; and for policy enforcement. 

Several kinds of architectural support help 
operating system designers meet these responsibil- 
ities: restriction of access to CPU facilities, 
restriction of memory use, memory mapping, sharing 
of programs and data, program relocation, stacks, 
context switching, an 1/0 system and interrupts, 
distributed controls and support for conventions. 
Both the Z8000 and the 68000 provide these kinds 
of support, but the Z8000 approach is more inte- 
grated and far-reaching. 

The most notable differences between the Z8000 and 
the 68000 are: 

• The support for virtual memory in the Z8000. 

• The lack of privileged 1/0 instructions and 
the scarcity of System Calls on the 68000. 

• The lack of a family concept in the 68000 
design, and the resulting lack of cohesion 
among the 68000 and its peripheral compo- 
nents. 

• The Z8000's greater flexibility in the speci- 
fication of interrupt vectors and the deter- 
mination of device priorities. 

• The lack of a provision for nonmemory process 
synchronization in the 68000 design. 

• The absence of support for message passing (or 
any other interprocess communication scheme) 
in the 68000 design. 

The Z8000 is seen to provide superior support for 
operating system functions. 
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Exploring 16-bit /iCs 



A tale of four j^Ps: 
Benchmarks quantify performance 

Aided by portions of the Carnegie-Mellon test package and 

with the cooperation of DEC, Intel, Motorola and Zilog, 
EDN compares the performance of four popular processors. 



Robert D Grappel, Consultant, 

and Jack E Hemenway, Consulting Editor 

In this article, EDN proudly publishes the results of 
the first comprehensive benchmark study of four major 
16-bit processors: the Digital Equipment Corp LSI- 
11/23, Intel 8086, Motorola 68000 and Zilog Z8000. 
You'll find these results highly interesting, and they 
should help you choose the best device for your 
application. 

Don't assume, however, that limiting the study to 
four devices implies that they are the four "best" 
machines; we hope that future articles will add new 
processors to the comparisons. Nevertheless, any 
benchmark study must start somewhere, and these 
machines seem representative of those used in today's 
systems. 

Why the need for a benchmark study at all? One sure 
way to start an argument among computer users is to 
compare each one's favorite machine with the others. 
Each machine has strong points and drawbacks, 
advantages and liabilities, but programmers can get 
used to one machine and see all the rest as inferior. 
Manufacturers sometimes don't help: Advertising and 
press releases often imply that each new machine is the 
ultimate in computer technology. Therefore, only a 
careful, complete and unbiased comparison brings 
order out of the chaos. 

The benchmarking process isn't a new one; Special 
Features Editor Robert Cushman has explored much 
the same ground for older processors that this article 
does for newer ones (EDN, April 20, 1975, pg 41). The 
modern devices are more powerful, but the task of 
choosing the right one for a given application is no 
simpler. 

Who chose the benchmarks? 

Benchmarking anything as complex as a 16-bit 
processor is a very difficult task to perform fairly. The 
choice of benchmark programs can strongly affect the 
comparisons' outcome, so the benchmarker must choose 
the test cases with care. The programs used in this 
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article were compiled in 1976 by a group at Carnegie- 
Mellon University for use in benchmarking minicom- 
puters and mainframes. The group presented the 
results of those benchmark tests at the 1977 National 
Computer Conference in the paper "Evaluation of 



Benchmark A — I/O interrupt kernel 

The test case chosen for this benchmark consists of 
one interrupt at each of the four levels. The times 
shown are the sum of the four interrupts, computed 
by counting the number of the instruction cycles by 
hand and including the time required for the 
processor to recognize and process an external 
interrupt. 



Processor 



Code Bytes 



Execution 
Time (ixsec) 
114 
126 (note) 

33 

42 



Clock Speed 

(MHz) 

LSI-11/23 3.33 20 

8086 10.00 55 

68000 10.00 24 

Z8000 6.00 18 

Note that the 8086 implementation of this 
benchmark saves the complete machine context on 
the stack; it's the only implementation that does so. 

| INTERRUPT | 
| DISABLE | 



I SAVE CONTEXT I 

T 



ENABLE HIGHER PRIORITY INTERUPTS 



SIMULATE PROCESSING 

DISABLE 

| RESTORE CONTROL | 



Fig 1 — This benchmark tests a processor's basic interrupt 
capability. Some machines require external hardware, while 
others put limitations on the number of interrupt vectors 
supported. 
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When faster chips are developed, 
execution times will decrease 



Computer Architectures via Test Programs," by S H 
Fuller, P Shaman, D Lamb and W E Burr. 

The set of programs includes many common algo- 
rithms that appear frequently in real-world applica- 
tions. They test the ability of a computer to handle data 
in chunks ranging from individual bits to 32-bit integers 
to floating-point numbers. The tests include interrupt 
handlers and character-string searches, bit manipula- 
tions and sorting. Taken as a set, they encompass a fair 
test of a computer's real power. 

For our benchmark tests, we have chosen a subset of 
this Carnegie-Mellon set; we have not included the 
benchmarks dealing with floating-point math or 
virtual-memory handling. We excluded floating-point 
math because most of the 16-bit processors don't 
support floating-point operations; we would thus have 
ended up benchmarking their floating-point software or 
external math processors. Similarly, the processors 
don't provide virtual-memory support. We also exclud- 
ed two benchmarks that require extensive number- 
crunching capability (Fourier transforms and Runga- 
Kutta integration) because their results would depend 
so heavily on the floating-point support used. The 
remaining seven benchmarks (labeled A, B, E, F, H, I 
and K in the Carnegie-Mellon literature) provide a 
sufficient test of each processor without handicapping 
any of the contestants. 

Who coded the benchmarks? 

Clearly, once you've chosen a benchmark set, coding 
it is the next critical task. We wanted to show each 
machine in the best possible light. Therefore, we asked 
a representative of each manufacturer to code the set 
for that manufacturer's machine, assuming that the 
manufacturer would best understand its machine's 
features. 

To referee this process, EDN then reviewed each 
program. Additionally, we circulated copies of each 
program for comments to the programmers of each of 
the other computers. This process ensured careful 
proofreading and close adherence to the benchmark- 
test rules. 

We did allow minor variations in the benchmark 
implementations where we felt they were justified. 
Two of the processors (the 8086 and Z8000) have special 
character-string instructions — we didn't want to pena- 
lize these devices by forcing their manufacturers to 
code unnecessary loops. Additionally, the 8086 has no 
general bit-manipulation instructions — a feature that 
sometimes produced differences among the bit-level 
benchmark implementations. The processors also differ 
widely in their extended-addressing capabilities, so we 
allowed some latitude in addressing mechanisms. 

The manufacturers coded each benchmark in assem- 
bly language, for several reasons. First, of course, 



Benchmark B— I/O kernel with FIFO 
processing 

The test data for this benchmark consists of the 
following set of interrupts: 

• Level 1 once 

• Level 2 once 

• Level 3 once 

• Level 4 once 

• Level 2 three times (forces queueing of 
interrupts) 

• Level 3 five times. 

The times shown are the sum of all of these 
interrupts. We hand-computed these times by 
counting instruction cycles, assuming worst-case 
arrival times. 
Processor Clock Speed Code Bytes Execution 



LSI-11/23 
8086 
68000 
Z8000 



(MHz) 
3.33 
10.00 
10.00 
6.00 



86 
85 
118 
106 



Time {yjsec) 

1196 

348 

390 

436 



I/O INTERRUPT 



X 



\ DISABLE INTERRUPTS \ + \ SAVE CONTEXT [ ~»> j IDENTIFY DEVICE | 



QUEUE 
SERVICE REQUESTS 



RESTORE CONTEXT 



ENABLE INTERRUPTS 



SET RUN FLAG OFF I 




SET RUN FLAG ON I 



SELECT NEXT 
REQUEST (FIFO) 



Ienable interrupts 



SIMULATE 
PROCESING 




N0 | DISABLE INTERRUPTS | 



REMOVE REQUEST 
FROM QUEUE 



Fig 2 — Extending Benchmark A, this test includes a FIFO 
buffer that queues interrupts as they arrive. The 68000 and 
Z8000 FIFO implementations trade a few words of memory for a 
fast and simple queue structure. 



there is no mutually acceptable high-level language 
available on all the machines. But in any case, EDN 
wanted to benchmark the processors and not the 
capabilities of compiler writers. The documentation 
provided to each programmer was the Carnegie-Mellon 
specification, in the form of flowcharts or a PASCAL- 
like pseudocode. The representatives required several 
iterations to get all the programs to work and then to 
optimize them; the final code appears at the end of this 



3-86 



EDN APRIL 1, 1981 



article. 

We provide the complete source-code listing of each 
benchmark on each machine for two reasons. First, 
readers can then duplicate the benchmarks on their own 
machines. Many "benchmark" numbers have appeared 
in print as new processors are introduced, but without 
a display of the coding, these numbers have no real 
basis. Second, a good program's "flavor" and "style" 
reveal much about the way you should program a 
particular processor. And these are carefully written 
and carefully checked programs produced by experi- 
enced programmers. 

An I/O interrupt kernel tests Interrupts 

With this background information in mind, you can 
examine each benchmark test. Benchmark A tests a 
computer's interrupt-handling capability; the flowchart 
in Fig 1 illustrates the task to be performed. An I/O 
interrupt with priority 0, 1, 2 or 3 occurs from one of 
four devices. The actual interrupt handler merely 



Benchmark E— Character-string search 

The test data used for this benchmark is a string 
containing the following 120 characters: 

000000000000000000000000000000 
00000Q000000000000000000000000 
HERE0OOOOOOOOOOOOOOOOOOOOOOOOO 
HERE IS A MATCH000000000000000 
The search argument was the string "HERE IS A 
MATCH". Motorola calculated the 68000 timing by 
hand; the other times come from executing the 
program on test machines, using real-time clocks or 
logic analyzers. 
Processor Clock Speed Code Bytes Execution 

(MHz) Time {usee) 

LSI-11/23 3.33 76 996 

8086 10.00 70 193 

68000 10.00 44 244 

Z8000 6.00 66 237 



LOC ; 



-1 



do for all I such that <= I <= SRCHLNGTH-SRCHARG or until LOC < 
if the substring of SRCHSTR from I to I+ARGLNGTH-1 - SRCHARG 

then LOC :- I 
end-if 

end-do 



Fig 3<— The character-string search is a commonly used test 
The 8086 and Z8000 have special string-handling instructions 
that can serve to advantage in applications like this. 



counts the device-interrupt occurrences. 

The interrupt handler must be able to pre-empt 
processing lower priority interrupts and must provide 
for resumption of the processing of lower level 
interrupts from the point of pre-emption. As much 
processing as possible should occur with interrupts 
enabled. 

This benchmark must take into account the existence 
of interrupt-prioritizing hardware, whether on the 
processor itself or as added peripheral components. 
Some of the steps in the flowchart are automatic in 



some machines. 

Benchmark B (Fig 2) also assumes four interrupting 
devices, except that here the interrupts are handled on 
a first-in, first-out basis rather than by priority. A 
queue with space for at least 10 pending interrupts 
must be provided. Processing of queued interrupts 
occurs with I/O interrupts enabled; thus, interrupts are 
accepted and queued appropriately while previous 
interrupts are processed. Before returning to the 
originally interrupted application program, the code 
must check whether any interrupts remain queued; if 
so, it must process them in FIFO order. 

Benchmark E appears in PASCAL-like form in Fig 3. 
This familiar task searches a text string for the 
existence of a text substring. If the string search is 
successful, the routine returns the substring's position 
in the data string. Otherwise, it returns a "not-found" 
indicator. A satisfactory program for this task must be 
re-entrant and position independent. 

Benchmark F (Fig 4) checks a processor's primitive 
bit-manipulation capabilities. It assumes a tightly 
packed bit string starting on a word boundary. A 
function code (F) chooses the appropriate operation 
from among Test (F=l), Set (F=2) and Reset (F=3). 
Bits are numbered relative to the bit string's starting 
address. This program, too, must be re-entrant and 
position independent. 

Linked-list insertion— a common problem 

Benchmark H (Fig 5) deals with inserting new 
entries into a doubly linked list. The Key field in each 
entry is a 32-bit integer value. This benchmark 
exercises a processor's addressing capabilities and also 
checks its ability to compare 32-bit quantities. 

Each entry in the list has a Key and a forward and 
backward pointer: The first list entry's backward 
pointer is zero; the last entry's forward pointer is zero. 
New entries must be inserted in ascending order of 
their Keys. The benchmark assumes the existence of a 
list-control block (LISTCB) that holds a pointer to the 
first entry in the list (HEAD), a pointer to the last 
entry in the list (TAIL) and a count of the number of 
entries in the list (NUMENTRIES). Like programs for 
Benchmarks E and F, this one must be re-entrant and 
position independent. 

Benchmark I (Fig 6) is the well-known Quicksort 
algorithm, which tests a processor's ability to manipu- 
late stacks and also gives the device's addressing modes 
a workout. This is by far the most complicated 
benchmark in the set, and manufacturers' coding of it 
exhibits the widest variation. 

The benchmark specifies N 16-byte records. The data 
array REC actually holds N+2 records, with RECO 
holding the lowest key value and RECN+1 the highest. 
A program must sort the records, based upon a key 
formed from the characters in each record's third 
through ninth bytes. Hence, this benchmark also tests 
character manipulations. Parameter M specifies the 
changeover point between Quicksort and a simple 
insertion sort. This program, too, must be re-entrant 
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programs for its processor 



and position independent. 

Finally, Benchmark K (Fig 7) transposes a matrix of 
bits. This test further checks out a processor's 
bit-manipulation facilities, as well as exercising loop 
constructs. It assumes a tightly packed bit matrix 
starting on a word boundary, and its program must be 
re-entrant and position independent. 

On your marks, get set,... 

Before examining the programs themselves, pause 
and recall the |xP state of the art a scant few years ago. 
A programmer would have been hard pressed to write 
many of these benchmarks on the 8-bit |iPs available 
then; for one thing, the requirements of position 
independence and re-entrancy would have caused 
nightmares. In this light, the power of all the 
processors described in this article is very impressive. 

Turning now to the benchmark programs, we note 
that all of them appear to be properly coded and bug 
free. However, some differences among them deserve 
comment. 

There's a major difference in "philosophy" between 
machine designers and programmers who favor 
registers and those who favor memory — a fact that's 
especially clear in the case of passing parameters to 
subroutines. Note in this regard that the various 
processor manufacturers are not especially consistent 
in this area. The LSI- 11/23 programs use the stack for 
parameters; the 68000 and 8086 sometimes use the 



stack and sometimes use registers; the Z8000 uses 
registers exclusively. Because our benchmark specifica- 
tions merely say "re-entrant," either method is 
satisfactory, provided that the programs furnish 
register-save and -restore instructions. Using the stack 
is "cleaner," but registers are usually faster. 

A problem of benchmark interpretation is apparent 
for the specification of Benchmark A: What does "Save 
Context" mean? One reading would suggest making a 
copy of the machine state (registers, program counter, 
condition codes, etc) while another might argue that all 
the spec calls for is saving the contents of any registers 
actually used (assuming that the actual interrupt- 
processing routines save and restore registers). 
Clearly, you get more compact code and faster 
execution times by choosing the "save only what is 
used" approach; only Intel performed an explicit and 
complete context-save operation. 

Also observe that several of the interrupt bench- 
marks use special hardware. The 8086 version, for 
example, assumes that an 8259 PIC chip is available to 
field and prioritize interrupts. And the LSI-11/23 has 
fully vectored interrupt hardware. (Thus, the interrupt 
benchmarks would run slightly slower on an LSI-11/2, 
because the processor is without such hardware.) The 
Z8000 assumes device daisy chaining, while the 68000 
uses its built-in vectoring. 

Finally, note the ONTRACE and OFFTRACE 
instructions in some of the LSI-11/23 code. DEC has 
used these commands to trigger a logic analyzer at the 
start and end of each routine being timed. Other 
benchmark programs also contain instructions intended 
for timing purposes. We didn't include these instruc- 
tions in our code-byte totals, though. 



Benchmark F— Bit set, reset, test 

The test data for this benchmark is an array of 1 25 
bits consisting of alternating ZEROs and ONEs. The 
array begins on a word boundary. The times shown 
are the sum of the following nine tests: 

Test Function Bit Number 

1 TEST 10 

2 TEST 11 

3 TEST 123 

4 SET 10 

5 SET 11 

6 SET 123 

7 RESET 10 

8 RESET 11 

9 RESET 123 

Note that the processors should perform these 
tests in this order without resetting the bit string. 
Motorola and Intel hand-computed their times; the 
others come from actual computer runs with 
reaMime clocks or logic analyzers. 
Processor Clock Speed Code Bytes Execution 
(MHz) Time (p-sec) 



LSI-11/23 


3.33 


70 


799 


8086 


10.00 


46 


122 


68000 


10.00 


36 


70 


Z8000 


6.00 


44 


123 



procedure BITTEST(F,N f Al,RC,WORK) 
integer ABIT,D 

ABIT := Al+N/(word length) 
D := N mod (word length) 

if Dth bit at address ABIT-1 

then RC := 1 

else RC := 
end-if 

if F = 2 

then Dth bit at address ABIT := 1 
else if F = 3 

then Dth bit at address ABIT := 
end-if 
end-if 

Fig 4 — Benchmark F exercises each processor's bit- 
manipulation capabilities. The 8086 and Z8000 use a somewhat 
different algorithm than the other two devices; they always test 
the specified bit, regardless of the function code. If they then find 
the bit to be ZERO and the function to be Reset, they merely 
return. On the other hand, if they find the bit to be ONE and the 
function Set, they also return. Finally if the function is Test, they 
can return regardless of the bit value. This version of the 
algorithm saves some execution time at the expense of code 
that's not as clear. The 8086 doesn't have the bit-manipulation 
instructions of the other processors, so it must use shifts and 
other instructions to perform the bit-manipulation operations. 
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Benchmark H — Linked-list insertion 

This data set starts with an empty list, into which five 
records are inserted with keys (32-bit hexadecimal 
numbers), as shown. The timings are for the sum of 
all five insertions: 

1. 12345 

2. 12300 

3. 13344 

4. 12345 

5. 34126 



Motorola hand-computed the 68000 timings; the 
remainder come from real-time clocks or logic 
analyzers. 



Processor 


Clock Speed 


Code Bytes 


Execution 




(MHz) 




Time (^sec) 


LSI-11/23 


3 33 


138 


592 


8086 


10 00 


94 


— 


68000 


10 00 


106 


153 


Z8000 


6.00 


96 


237 



procedure LISTINSERT(LISTCB,NEWENTRY) 

"the notation POINTER. FIELD is used to access a 
particular field of the structure pointed to by POINTER" 

pointer PRESENT 

if LISTCB.NUMENTRIES ■ 
then 

"list is empty, so initialize" 

LISTCB.HEAD := LISTCB.TAIL := NEWENTRY 

LISTCB.NUMENTRIES := 1 

NEWENTRY. NEXT := NEWENTRY. PR EV := 



"list not empty" 

PRESENT := LISTCB.HEAD 
LISTCB.NUMENTRIES := LISTCB.NUMENTRIES+1 

"determine position of new entry" 

while NEW. KEY >= PRESENT. KEY and PRESENT. NEXT <> do 
PRESENT := PRESENT. NEXT 



Fig 5— Linked-list insertion using a 32-bit key value tests many 
aspects of a 16-bit processor's architecture. This benchmark 
exercises the addressing modes of each device. 



if PRESENT. PREV = and NEW. KEY < PRESENT. KEY 
then 

" new list head " 

LISTCB.HEAD := NEW 
NEW. PREV := 
PRESENT. PREV := NEW 
NEW. NEXT :=• PRESENT 
else 

if NEW. KEY >= PRESENT. KEY 
then 

"new list tail" 

PRESENT. NEXT := LISTCB.TAIL := NEW 
NEW. NEXT := 
NEW. PREV := PRESENT 
else 

"insert in middle" 

NEW. NEXT := PRESENT 
NEW. PREV := PRESENT. PREV 
PRESENT. PREV := NEW 

"back up and link predecessor" 

PRESENT := NEW. PREV 
PRESENT. NEXT := NEW 



end-if 
end-if 
end-if 



Memory limitations surface 

A major feature of the new 16-bit processors is their 
ability to address large memories. Unfortunately, many 
of the benchmark programs were coded in a way that 
limits them to a 64k-byte range; only the Motorola 
68000 programs are truly usable over the machine's full 
addressing range. 

The LSI-11/23 and Z8000 benchmarks assume a 64k 
data space, because they use only 16-bit addressing. 
For example, in Benchmark E, the character-string 
search, neither of these machines can (with the coding 
shown) deal with the case where the search substring 
and the data string are not in the same 64k space. In 
that case, you'd require additional coding to handle the 
segment information, necessary to extend the pro- 
grams to the processor's full addressing range. 

In the same vein, the 8086 benchmark programs 
frequently assume that the calling program and the 
subroutine share data and stack segments — an assump- 
tion that also limits the subroutine's addressing range. 
For example, the character-string-search Benchmark 
(E) assumes that the string to be searched is in the 
extra segment (ES). This must be the case to make the 
compare-string (CMPS) instruction work properly; if 
the string were not already in the extra segment, you 
would need code to change the segment addressing. 

The 8086 coding of the Quicksort (Benchmark I) uses 
a clever trick involving the 8086 segment registers to 
gain efficient indexing of the data records. Unfortu- 



nately, this trick only works because the records are 
exactly 16 bytes long. Because the 8086 addressing 
system internally multiplies each segment by 16, 
putting a record number in the segment register 
automatically points to the appropriate address. 
Executing Quicksort for records of any other length, 
though, would require rewriting the Intel program. 
Modification of this routine for general record lengths 
would increase code size by an estimated 25% worst 
case (this also allows records extending over segment 
boundaries) while affecting performance by no more 
than an estimated 5%. The performance degradation 
occurs only for segment-boundary checks, record- 
length incrementing through the array (rather than 
segment-register incrementing) and segment-boundary 
transitions. The code expansion arises from segment- 
boundary-transition logic that's infrequently — if ever — 
invoked. 

Note that the Zilog benchmarks shown are coded for 
the Z8002 (unsegmented) version of the Z8000. On the 
segmented (Z8001) version, these programs would be 
virtually identical: Except for the I/O-interrupt-kernel 
benchmarks, all of the programs use exactly the same 
number of bytes for both devices. (The I/O-interrupt- 
kernel routines use direct addressing for some varia- 
bles.) Execution times for the Z8001 benchmarks would 
tend to be longer than the Z8002 times, though, 
because of such factors as 

• 32-bit Load instructions for address moving 
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• More registers to save and restore 

• The longer execution time of the RET instruction 

• The longer time required for direct addressing. 

What did we measure? 

Two statistics are important in computer bench- 
marks: program size and speed. A program's size is 
easy to measure — -just add up the bytes. Our ground 
rule in this regard was "If you placed the program in 
ROM, how much ROM would be used?" We didn't count 
stack space. (There are no local variables, because the 
benchmarks are re-entrant.) 

Speed values, on the other hand, are very difficult to 
get a handle on: It seems that the chip makers produce 
faster ijlPs weekly. The memory you use can also affect 
the execution speed, thanks to such factors as 
dynamic-memory refresh. Therefore, because it wasn't 
possible to obtain a consistent timing mechanism for all 
of the benchmarks, the timing information provided is 
merely what the programmers themselves measured 



(or in Motorola's case, calculated). We do include data 
on the processors' clock rates, as well as on how the 
timings were obtained. And we also performed spot 
checks on the timing figures provided, using our 
experience in working with these processors to ensure 
that the times were reasonable. 

Execution times for the 8086-, Z8000- and 68000- 
based single-board computers assume on-board mem- 
ory-access operations. By contrast, results for the 
LSI-11/23 are based on the use of standard off-board 
dynamic-RAM systems and an asynchronous bus for 
instruction and data transfers — a configuration dictat- 
ing the use of processor Wait states, which slowed 
speeds somewhat. DEC points out, however, that the 
LSI-ll/23's performance figures reflect the actual 
operation of current board-level product offerings and 
that the data doesn't necessarily reflect a limitation of 
the board's processor chip set. 

Finally, note that we list the clock speeds of the 
fastest boards currently available; ie, we have 10-MHz 
units from Intel and Motorola running in our lab. 
However, we expect that the manufacturers will build 
even faster machines in the future. For example, Zilog 
plans to introduce a 10-MHz version of the Z8000 within 
the next 3 months. Because faster processors obviously 



Benchmark I— Quicksort 

The test data for this benchmark consists of 102 Note that only the key values (bytes 3 to 9 in each 
(N= 100) records, each 1 6 bytes long. Parameter M record) are significant. All data values are hexadeci- 
is set to nine. The records are initialized as follows: mal bytes. As in the previous benchmarks, the 

Record - - - 00 00 00 00 00 00 00 68000 times are hand computations; the others are 

Record 1 — FF 00 00 00 00 00 00 the results of program runs. No data is available for 

Record 2 - - - FE 00 00 00 00 00 00 the LSI-11/23 on this benchmark. 

Record 3 - - - FD 00 00 00 00 00 00 Processor Clock Speed Code Bytes Execution 

(MHz) Time (n-sec) 

LSI-11/23 3.33 — — 

8086 10.00 347 115,669 

68000 10.00 266 33,527 

Record 100 - - - 9C 00 00 00 00 00 00 Z800 o 6.00 386 115,500 

Record 101 - - - FF FF FF FF FF FF FF 



procedure QUICKSORT (N,REC,M, WORK) 


else 


integer L,R,I,J,K 


push lower and upper limits of larger 


integer array STACK[0:2*F(N)-1] 


subfile onto stack 


character string V 


set L and R to limits of smaller subfile 




end-if 


REC[N+1] := oo 


end-if 


L := 1; R := N 


end-do 


do forever 




I := L; J := R+l; V := REC[L] 


end-outer: 


do forever 


do for I from N-l to 1 in steps of 1 


do I :■ 1+1 until REC[I] >= V end-do 


if REC[I] > RECII+1] then 


do J := J-l until REC[J] <= V end-do 


V := RECII] ; J := J+l 


if J > I 


do forever 


then swap REC[I] with REC[J] 


REC[J-1] := REC[J]; J := J+l 


else goto end-first 


if REC[J] >= V then goto end-last end-if 


end-if 


end-do 


end-do 






end-last: 


end-first: 


REC[J-1] := V 


swap REC[L] with REC[J] 


end-if 


if both subfile sizes (J-L and R-J) <= M 


end-do 



then 

if stack is empty 
then goto end-outer 
else pop L and R from stack 
end-if 
else 

if smaller subfile size <= M 

then set L and R to lower and upper limits 
of larger subfile 



Fig 6 — The Quicksort requires most work from a processor of 
any of the benchmarks, and it's typical of a type of application 
that these devices must frequently serve. The 8086 implementa- 
tion depends on the 16-byte length of each record and can't be 
used for general sorting of records of differing length. 
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Benchmark K— Bit-matrix transposition 

The test data for this benchmark consists of 49 bits 
in a 7x7 array: 

0100100 
1010111 
0010001 
1101010 
0101000 
0000101 
1100101 
The array begins on a word boundary. Timing for 
the 68000 was hand -computed; the other times 
come from test runs. 
Processor Clock Speed Code Bytes 
(MHz) 

3.33 152 

10.00 88 

10.00 74 

6.00 110 



LSI-11/23 
8086 
68000 
Z8000 



Execution 
Time (ixsec) 

1517 

820 

368 

646 



procedure pMT(N,Al,A2) 
integer I, J 
boolean B[1:N,1:N] beginning at bit A2 of word Al 



do for $11 I and J such that (I <= 

swap B[I,J] and B[J,I} 
end-do 



N) and (J+l 



Fig 7 — Transposition of a bit matrix is another exercise of a 
processor's bit-manipulation capabilities. The availability of 
instructions to dynamically test, set and clear individual bits in a 
word is an advantage in this case. 



produce shorter execution times, keep such technologi- 
cal progress in mind if your design project has a long 
development time or can allow for future upgrading. 

"Just the facts, ma'am" 

The data in the accompanying boxes summarizes the 
benchmarking results in terms of code size and 
execution speed. And the program listings that follow 
this article illustrate the codings for each processor. As 
noted, we assume that the manufacturers have done a 
good job of optimizing the benchmarks; if they don't 
know how to write code for their own devices, who 
does? 

If there are bugs in the code or ways to improve the 
coding, EDN would like to know. We have made every 
effort to check the benchmark programs for correct- 
ness and adherence to the specifications. And we thank 
each of the manufacturers for providing a substantial 
investment of time and manpower in coding, checking 
and documentation. We leave any conclusions to you, 
the reader. 

( Ed Note : Some of the benchmarks were not complete 
at the time this article was prepared. Specifically, the 
LSI -11 123 Quicksort (Benchmark I) was incomplete, 
and one of the 8086 timings remained to be determined. 
We have left the entries for these values blank.) 
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1 

2 
3 

4 

5 

6 

7 

8 

9 
10 
11 
12 
13 

14 000000 
15 
16 

17 000300 

18 000302 
19 

20 

21 000302 

22 000304 
23 

24 

25 000304 

26 000306 
27 

28 

29 000306 

30 000310 
31 

32 000000 

33 

34 

35 

36 

37 

38 

39 

40 

41 

42 

43 

44 000000 

45 000000 

46 000002 




.TITLE. BENCHMARK A 
.IDENT /OCT. 22/ 
.ENABL LC 




; I/O INTERRUPT KERNEL, FOUR PRIORITY LEVELS 




; Services Interrupts from four levels, produces a count of Interrupts 
; by level. 




; The following "ASECT" or absolute program section will load up 
; four interrupt vectors. 




•ASECT ; absolute 


000300 

000000' 

000200 


. = 300 

INT1 

200 ; execute at priority 4 


000302 

000006' 

000240 


. » 302 

INT2 

240 ; execute at priority 5 


000304 

000014' 

000300 


. = 304 

INT3 

300 I execute at priority 6 


000306 

000022' 

000340 


. ■ 306 

INT4 

340 ; execute at priority 7 




.PSECT ; relocatable 


005227 
000000 


; Hardware saves context: program counter and processor status. 

; Hardware masks out lower level Interrupts. 

; Hardware vectors to one of the four interrupt service routines. 

1 Interrupt service routine increments counter. 

; RTI instruction restores procressor status and program counter, 

; lower level Interrupts are re-enabled. 

; 

; Note: If ROMability was a requirement, this program would be four words 

; longer! 

; 

INTl: 

INC (PO + 

counti: o Continued on pg 186 
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1 

2 












OPT 


BRS,FRS 




3 
4 
5 
6 
7 
8 
9 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 
27 
28 
29 
30 
31 
32 
33 
34 
35 
36 
37 
38 
39 
40 
41 
42 
43 








* 






MC68000 EDN BENCHMARK A 












PRIORITY I/O INTERRUPT KERNEL, FOUR PRIORITY LEVELS 










* 
* 
* 
* 


NOTES: 


1) FOUR AUTOVECTORS ARE ASSUMED INITIALIZED 

TO POINT TO THE FOUR INTERRUPT ENTRY POINTS. 

2) THE MC68000 INTERRUPT SEQUENCE TAKES 4.7 
MICROSECONDS WITH AN ASSUMED INTERRUPT 
ACKNOWLEDGE BUS CYCLE OF 4 CYCLES. 

3) INTERRUPTS ARE TAKEN ANYWHERE WITHIN THE 
MC68000 16 MEGABYTE ADDRESS SPACE. 

4) THE MC68000 PROCESSES INTERRUPTS 

IN PRIORITY ORDER WITHOUT REQUIRING THE 
SUPPORT OF EXTERNAL CIRCUITRY. 








00000000 
00000004 


52780018 
4E73 


* LINES: 8 

* BYTES: 24 
* 

* MC68000L10 BENCHMARK TIME: 33.600 MICROSECONDS 

* INTERRUPT HANDLERS 

INTRPT1 ADD #l,COUNTERl INCREMENT COUNTER FOR 
RTE RETURN FROM EXCEPTION 


INTERRUPT 1 






00000006 
0000000A 


5278001A 
4E73 


INTRPT2 


ADD 
RTE 


#l,COUNTER2 INCREMENT COUNTER FOR 
RETURN FROM EXCEPTION 


INTERRUPT 2 






0000000C 
00000010 


5278001C 
4E73 


INTRPT3 


ADD 
RTE 


#l,COUNTER3 INCREMENT COUNTER FOR 
RETURN FROM EXCEPTION 


INTERRUPT 3 






00000012 
00000016 


5278001E 
4E73 


INTRPT4 


ADD 
RTE 


#l,COUNTER4 INCREMENT COUNTER FOR 
RETURN FROM EXCEPTION 


INTERRUPT 4 








00000018 
0000001A 
0000001C 
0000001B 


0000 
0000 
0000 
0000 


* INTERRUPT COUNTERS 

COUNTER1 DC COUNTER FOR INTERRUPT 
COUNTER2 DC COUNTER FOR INTERRUPT 
COUNTER3 DC COUNTER FOR INTERRUPT 
COUNTER4 DC COUNTER FOR INTERRUPT 


1 
2 
3 
4 


44 
45 












END 






****** 


TOTAL ERRORS — 














0000 6900 
0002 0000' 
0004 7B00 
0006 6900 
0008 0002 1 
000A 7B00 
000C 6900 
000E 0004' 



BENCHMARK A— Z8000 



lExample A: I/O Interrupt Kernel, Four Priority Levelsl 
IDefinitions for interrupt kernel programs: 1 



SYSMEM := %5000 
SYSTACK := SYSMEM 
SP :■ R15 
SPOFF := R15 



1 Addresses for basic system uses! 
256 lOne word past highest stack adr! 
IStack register (RR14 for Seg) ! 



REASON 


:= Rl 




QUEPTR 


:= R2 


1RR2 for segmented I 


QUENXT 


:= REASON 




ADRLEN 


:= 2 


14 for segmented 1 


JUMP 


:= ADRLEN + 2 




ENTOFF 


t» ADRLEN 





J The four routines that follow are the processing routines for 
the four priority levels. VI0 is the highest priority routine, 
VI3 the lowest. Each of these routines is reached in response 
to an interrupt on the vectored interrupt (VI) line. Priority 
resolution is through a hardware protocol defined as part of the 
Z8000 family architecture. Each of the four devices assumed to 
be attached to the VI line places its own identifier on the bus 
when it interrupts, and this identifier is used by the CPU for 
automatic vectoring to the appropriate routine. The addresses 
of the routines appear in the program status area (see below) . 
The flag/control word (FCW) value assembled into the PSA has the 
vectored interrupt enable (VIE) bit set, so that each processing 
routine is interruptible by other vectored interrupt devices. 
The hardware interconnection protocol assures that interrupts 
come only from higher priority devices. 

1 

VI0: INC VICNT0 

IRET 
VII: INC VICNT1 



IRET 

INC VICNT2 



Continued on pg 196 
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0010 7B00 
0012 6900 
0014 0006' 
0016 7B00 


IRET 
VI3: INC VICNT3 

IRET 


0000 OOOO 
0002 OOOO 
0004 OOOO 
0006 OOOO 


ICounters for simulated four priority level processing 1 
VICNT0: 
VICNT1: 
VICNT2: 
VICNT3: 





BENCHMARK B-LSI-11/23 


1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 




.TITLE BENCHMARK B 
.IDENT /OCT. 22/ 
.ENABL LC 




I/O INTERRUPT KERNEL, FIFO PROCESSING 




Services interrupts from four levels, using a FIFO queue. 

Each of the four devices has an Interrupt vector set up as follows 




. = vector address 
.WORD ROUTINE, 340 


13 

14 

15 

16 

17 

18 

19 OOO00O 

20 


; The vectored Interrupt capability of the LSI-11 hardware is used 
; here to Implicitly identify the device causing the interrupt. 
? Each Interrupt will vector to a different service routine. 
; Hardware will save context (program counter - PC, and processor 
; status " PS) at the interrupt. 




.ASECT 


21 
22 
23 
24 




Set up a vector for each device. 


000300 


. s 300 


25 000300 

26 000302 
27 

28 000304 

29 000306 
30 

31 000310 

32 000312 
33 

34 000314 

35 000316 
36 

37 

38 

39 

40 

41 

42 

43 

44 

45 

46 

47 

48 000000 

49 

50 

51 

52 

53 000000 

54 000040 

55 000042 

56 000044 
57 

58 000000 

59 

60 

61 

62 

63 

64 

65 

66 


000000' 
000340 


DEVI ; new PC 
340 ; new PS 


000006' 
000340 


DEV2 
340 


000014' 
000340 


DEV3 
340 


000022' 
000340 


DEV4 
340 




Each device operates at priority seven (340 octal in the PS) to disable 
other interrupts. 




The queue contains a power of two number of words. It must begin on 
an even multiple of the queue size, such that for all addresses in 
the queue, (address and queue size) is zero, and ((queue start + 
> queue size) AND queue size) is nonzero. QEND points to where the 

• next new entry will be made in the queue. QSTART points to where the 

• next entry will be removed from the queue, when they point to the 

' same place, the queue is empty, we assume the queue never overflows. 
• 

.PSECT DATA 


000040 OSIZE = 40 ; sixteen elements 

; QUEUE will be relocated to 
; address 1000(8) at LINK time 
QUEUE: .BLKB OSIZE 

000000' OSTART: QUEUE 

000000' QEND: QUEUE 

000000 runflg: 




.PSfeCl CUDF 




Each of the four devices has an interrupt routine as follows: 




ROUTINE: 

any immediate processing 

CALL COMMON 
CIR: .WORD 


67 
68 
69 
70 

71 000000 

72 000000 

73 000004 
74 

75 000006 

76 000006 

77 000012 
78 

79 000014 




CTR is the counter that will be Incremented by the FIFO processor. 
In a real example, It would be the first Instruction of the 
interrupt service routine. 


1 
004767 000024 
000000 ( 


;EVl: 

CALL COMMON 

:tri: .WORD 


I 
004767 000016 
000000 ( 


)EV2: 

CALL COMMON 
:tr2: .WORD 


I 


>EV3: Continued on pg 200 
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70 


00000036 


3050 




MOVE 


QUELINK(A0) ,A0 


71 


00000038 


B0F8004A 




CMP 


QUEIN, A0 


72 


0000003C 


66EA 




BNE 


SELECT 


73 


0000003E 


42380074 




CLR.B 


FLAG 


74 












75 






* RESTORE CONTEXT 




76 


00000042 


4CDF0300 


RETURN 


MOVEM.L 


(SP)+,A0/A1 


77 


00000046 


588F 




ADD.L 


#4,SP 


78 


00000048 


4E73 




RTE 




79 












80 












81 






* QUEUE 


POINTER 




82 


0000004A 


004C 


QUEIN 


DC 


QUEUE 


83 












84 






* QUEUE 


PROPER 




85 


0000004C 


00500000 


QUEUE 


DC 


*+4,0 


86 


00000050 


00540000 




DC 


*+4,0 


87 


00000054 


00580000 




DC 


*+4,0 


88 


00000058 


005C0000 




DC 


*+4,0 


89 


0000005C 


00600000 




DC 


*+4,0 


90 


00000060 


00640000 




DC 


*+4,0 


91 


00000064 


00680000 




DC 


*+4,0 


92 


00000068 


006C0000 




DC 


*+4,0 


93 


0000006C 


00700000 




DC 


*+4,0 


94 


00000070 


004C0000 




DC 


QUEUE, 


95 












96 






* INTERRUPT IN PROGRESS FLAG 


97 


00000074 


00 


FLAG 


DC.B 





98 












99 








END 




***** 


TOTAL ERRORS 0— 










LOAD NEXT IN LIST 
TEST END OF LIST 
PROCESS IT IF NOT 
SHOW NO ELEMENTS QUEUED 



RELOAD USERS REGISTERS 

CLEAN COUNTER ADDRESS OFF STACK 

RETURN FROM EXCEPTION 



NEXT ENTRY TO USE 



QUEUE ENTRY ONE 
QUEUE ENTRY TWO 



QUEUE ENTRY TEN 

INTERRUPT IN PROGRESS INDICATOR 
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iExampl 


e B: I/O Interrupt Kernel, FIFO 


Processing! 


0000 2DF1 


FIFOs 


EX REASON, @SP 


ISave the context! 


0002 93F2 




PUSH @SP, QUEPTR 


ISave registers 1 


0004 6102 




LD QUEPTR, QUEIN 


IQueue the request I 


0006 000E 1 








0008 3321 




LD QUEPTR ( #ENTOFF ), REASON 




000A 0002 








000C 2121 




LD QUENXT,@QUEPTR 




000E 6F01 




LD QUEIN, QUENXT 


!Set pointer to next slot 1 


0010 000E' 








0012 4C06 




TSETB FLAG 


ICan it be processed now? ! 


0014 003C 








0016 E50C 




JR MI,RESTOR 


1 No ! 


0018 7C06 


LOOP: 


EI NVI 


lYes, let more happen 1 


001A 3121 




LD REASON, QUEPTR (#ENTOFF) 


I Simulate processing by 1 


001C 0002 








001E 6810 




INCB COUNTS (REASON) 


1 bumping count 1 


0020 0008 • 








0022 7C02 




DI NVI 


IDisable before dequeing I 


0024 2122 




LD QUEPTR, @QUEPTR 


JCheck on next ! 


0026 4B02 




CP QUEPTR, QUEIN 


{Anything else in queue ? 1 


0028 000E' 








002A EEF6 




JR NE,LOOP 


1 Yes, do it ! 


002C 4C08 




CLRB FLAG 


! No, clear flag I 


002E 003C 








0030 97F2 


RES TOR: 


POP QUEPTR, §SP 


IRestore registers 1 


0032 2DF1 




EX REASON, @SP 




0034 7B00 




IRET 


!And return 1 




ICounters for FIFO interrupt processing 


! 


0008 


COUNTS 


array [5 byte] 






IQueue 


for FIFO interrupt processing 1 




000E 0010' 


QUEIN: 


QUEUE 




0010 0014' 


QUEUE: 


$+JUMP, 0, 




0012 0000 








0014 0018' 




$+JUMP, 0, 




0016 0000 








0018 001C 




$+JUMP, 0, 




001A 0000 








001C 0020' 




$+JUMP, 0, 




001E 0000 








0020 0024' 




$+JUMP, 0, 




0022 0000 








0024 0028' 




$+JUMP, 0, 




0026 0000 








0028 002C» 




$+JUMP, 0, 




002A 0000 








002C 0030' 




$+JUMP, 0, 




002E 0000 








0030 0034» 




$+JUMP, 0, 




0032 0000 








0034 0038' 




$+JUMP, 0, 




0036 0000 








0038 0010 ' 




QUEUE, 0, 




003A 0000 








003C 00 


FLAG: 
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1 

2 
3 

4 
5 
6 
7 










OPT BRS 










* 


MC68000 EDN BENCHMARK 


E 








* 


SUBSTRING CHARACTER SEARCH 








* 


ATTRIBUTES: * 16 MEGABYTE ADDRESSING RANGE 


8 








* 


* POSITION INDEPENDENT 




9 








* 


* REENTRANT 




10 








* 






11 








* 


INPUT ARGUMENTS: 




12 








* 


D0 - SEARCH PATTERN LENGTH A0 - 


SEARCH PATTERN STRING ADDRESS 


13 
14 
15 








* 


Dl - SEARCHED STRING LENGTH Al - 


SEARCHED STRING ADDRESS 








* 


OUTPUT: 




16 
17 
18 
19 
20 








* 


D2 - RETURNED MATCHED OFFSET VALUE (-1 IF NO MATCH) 








* 


ALL OTHER REGISTERS ARE TRANSPARENT OVER THIS ROUTINE 








* 


LINES: 18 




21 








* 


BYTES: 44 




22 








* 






23 
24 








* 


MC68000L10 BENCHMARK TIME: 


244.000 MICROSECONDS 


25 
26 








* 


REGISTER USAGE: 




27 








* 


D0 - COMPARE LOOP COUNTER A0 - 


SEARCHED STRING ADDRESS 


28 








* 


Dl - POSITION LOOP COUNTER Al - 


PATTERN STRING ADDRESS 


29 








* 


D2 - TOTAL LENGTH SAVE A2 - 


COMPARE TEMPORARY POINTER 


30 








* 


D3 - INITIAL CHARACTER A3 - 


COMPARE TEMPORARY POINTER 


31 
32 
33 








* 


D4 - COMPARE LOOP TEMP 










* 


INDEX FUNCTION SUBROUTINE 




34 





00000000 


48E71830 


INDEX MOVEM.L D3/D4/A2/A3 ,- (SP) 


SAVE WORK REGISTERS 


35 





00000004 


9240 




SUB D0,D1 


FIND SEARCH LOOP COUNT (-1) 


36 





00000006 


3401 




MOVE D1,D2 


ALSO USE FOR FINAL OFFSET COMPUTATION 


37 





00000008 


5540 




SUB #2,D0 


ADJUST COUNT FOR DBRA LOOP 


38 





0000000A 


1618 




MOVE.B (A0)+,D3 


D2=FIRST CHAR TO BE FOUND 


39 








* 


SEARCH FOR FIRST CHARACTER MATCH 




40 





0000000C 


B619 


FIND1 CMP.B (A1)+,D3 


SEARCH STRING UNTIL FIRST CHAR 


41 





0000000E 


57C9FFFC 


COUNT1 DBEQ D1,FIND1 


Dl GETS DECREMENTED FOR LOC CALCULATION 


42 





00000012 


6612 




BNE NOTFOUND 


BRANCH IF NO FIRST CHAR 


43 








* 


PERFORM FULL PATTERN COMPARE 




44 





00000014 


2448 




MOVE.L A0,A2 


A2=POINTER TO SUBSTRING 


45 





00000016 


2649 




MOVE.L A1,A3 


A3=POINTER TO STRING 


46 





00000018 


3800 




MOVE D0,D4 


D3=TEMP FOR SUBSTRING COUNTER 


47 





0000001A 


6B08 




BMI ONECHAR 


BRANCH IF ONLY ONE CHARACTER 


48 





0000001C 


B70A 


COMPARE CMP.B (A2)+,(A3)+ 


COMPARE REST OF SUBSTRING 


49 





0000001E 


56CCFFFC 




DBNE D4, COMPARE 


LOOP IF STILL EQUAL AND MORE 


50 





00000022 


66EA 




BNE COUNT1 


BRANCH BACK IF REST NOT THE SAME 


51 





00000024 


9441 


ONECHAR SUB D1,D2 


CALCULATE OFFSET OF MATCH 


52 





00000026 


4CDF0C18 


NOTFOUND MOVEM.L (SP) + # D3/D4/A2/A3 


RESTORE WORK REGISTERS 


53 
54 
55 





0000002A 


4E75 




RTS 


RETURN TO CALLER 










END 
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lExample E: Character S 


sarch ! 






lArguments : ! 












SRCHLNGTH 




= 


RO 


ILength (in bytes) of SRCHSTR! 






ARGLNGTH 




= 


R1 


ILength (in bytes) of SRCHARG I 






SRCHSTR 




= 


R2 


!Address of the string to be searched! 






SRCHOFF 




= 


R2 


!offset portion of address! 






SRCHARG 




= 


M 


!Address of string sought! 






ARGOFF 




= 


R4 


!0ffset portion of address! 






LOC 




r 


R6 


IReturn arg: char position (>=0) or ! 






FAILCODE 




= 


-1 


! negative (FAILCODE) if no match! 






Workspace for 


the 


routine : ! 






G 




= 


RH6 


!First char of sought string ! 






LCT 




= 


R7 


{Substring counter ! 






SCH 




= 


R8 


JAddress register used with ARCHARG! 






ARG 




= 


R10 


!Address register used with SRCHARG! 






OFFSAVE 




= 


R12 


[Remembers original SRCHOFF value! 






CT 




= 


R13 


!Count (bytes in srch string)! 






WK1 




= 


R7 








NW1 




= 


7 




0000 


ABFD 


SEARCH: DEC SP, 


#2»NW1 




0002 


1CF9 


LDM §SP 


,WK 


,#NW 


!Save registers used ! 


0004 


0706 










0006 


A107 


LD LCT, 


SRCHLNGTH ICompute number of substrings! 


0008 


8317 


SUB LCT 


, ARGLNGTH ! long enough to match! 
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OOOA A970 




INC LCT 






OOOC A12C 




LD OFFSAVE,SRCHOFF 




ISave initial SRCHOFF value! 


OOOE 2046 




LDB G,eSRCHARG 




IFirst char to look for! 


0010 A940 




INC ARGOFF 




!Set to compare remainder! 


0012 AB10 




DEC ARGLNGTH 




IChars in remainder! 




! Check 


possible substrings from 


left to right! 


OOU BA24 


CLOOP: 


CPIRB G,§SRCHSTR,LCT,EQ 


IMatch first char! 


0016 0766 










0018 EEOA 




JR NZ,FAIL 




!No match! 


001A 8D14 




TEST ARGLNGTH 




lAny more chars in string?! 


001C E60B 




JR Z, MATCH 




! no - already finished! 


001E A11D 




LD CT, ARGLNGTH 




!Set length and ! 


0020 A128 




LD SCH,SRCHSTR 




! string address! 


0022 A14A 




LD ARG,SRCHARG 




! for block comparison! 


0024 BAA6 




CPSIRB §SCH,@ARG,CT 


NE 


!Look for a mismatch ! 


0026 0D8E 










0028 EE05 




JR NZ, MATCH 




IStrings match , byte for byte! 


002A 8D74 




TEST LCT 




!No match - try next substring! 


002C EEF3 




JR NZ, CLOOP 




! (if any) ! 


002E 2106 


FAIL: 


LD LOC,#FAILCODE 




!No more substrings-fail! 


0030 FFFF 










0032 E803 




JR EXIT1 






0034 A126 


MATCH: 


LD L0C,SRCH0FF 




IMatch - return index of ! 


0036 83C6 




SUB L0C,0FFSAVE 




! substring matching initial ! 


0038 AB60 




DEC LOC 




! search string! 


003A 1CF1 


EXIT1: 


LDM WK1,eSP,#NW1 






003C 0706 










003E A9FD 




INC SP,#2*NW1 




IRestore registers ! 


0040 9E08 




RET 
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LSI-11/23 


1 








.TITLE 


BENCHMARK F 






2 








.IDENT 


/OCT. 22/ 






3 
4 

5 
6 
7 
8 
9 








.ENABL 


LC 










; BIT TEST, SET 


, OR RESET 










; Find 


a bit, check it, change it 


, bash it, smash it 






; Assumes that 


bits are numbered 


from from the right-hand end of a word. 


10 






; This 


is the way a PDP-11 


views 


words. Luckily lef t-to-rlght ordering 


11 






; fcas not a benchmark requirement 


1 Arguments are passed on the stack. 


12 






; Naturally, performance improvements could be made by passing tne arguments 


13 






; in registers. 








14 
15 
16 






; Stack 

; 


offsets 


assume 4 bytes for saved registers: 


000006 




F 


= 6 




function code 


17 


000010 






N 


= 10 


; 


relative bit number 


18 


000012 






Al 


= 12 


; 


address of bit string 


19 


000014 






RC 


= 14 


; 


address of return code word 


20 
21 
22 000000 


000016 






WORK 


* 16 


' 


not used 






ONTRACE 


:: 








23 000000 






btsr:: 










24 000000 


010046 






MOV 


RO, -(SP) 


; 


save registers 


25 000002 


010146 






MOV 


Rl, -(SP) 






26 000004 


005076 


000014 




CLR 


9RCCSP) 


; 


assume bit is zero 


27 000010 


016600 


000010 




MOV 


NCSP), RO 


; 


RO s bit offset 


28 000014 


042700 


177770 




BIC 


**C<7>, RO 


; 


RO s bit within byte 


29 000020 


012701 


000001 




MOV 


#1, Rl 


; 


Rl = 1 


30 000024 


072100 






ASH 


RO, Rl 


; 


shift the 1 in Hi left RO times 


31 000026 


016600 


000010 




MOV 


NCSP), RO 


; 


RO a bit offset 


32 000032 


072027 


177775 




ASH 


#-3, RO 


; 


RO = byte offset into Pit string 


33 000036 


066600 


000012 




ADD 


AHSP), RO 


; 


RO -> the byte address 


34 000042 


130110 






BIT8 


Rl, (RO) 


; 


checK out the bit 


35 000044 


001402 






BKQ 


10$ 


; 


branch if zero 


36 000046 


005276 


000014 




INC 


eRC(sp) 


; 


else return code becomes one 


37 000052 


026627 


000006 000002 


10$S 


CMP 


F(SP), #2 


; 


if function code Is two, 


38 000060 


001002 






BNE 


20$ 






39 000062 


150110 






BISB 


Rl, (RO) 


; 


set tne Dit 


40 000064 

41 

42 000066 


000405 






BR 


30$ 






026627 


000006 000003 


20$: 


CMP 


F(6R), #3 




ii function code is three, 


43 000074 


001001 






BNE 


30$ 






44 00007b 


140110 






B1CB 


Rl, (FO) 


; 


clear the bit 


45 OOGiOG 


012601 




30$: 


MOV 


CbP) + , i<l 


; 


restore registers 


46 000102 


012600 






MOV 


(SP)+, RO 






47 000104 






OFfTkACfc:: 








48 000104 
49 


000207 






KE1UKN 








50 
51 


000001 






.LNU 
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1 

2 
3 












OPT BRS 








* 






4 
5 
6 
7 
8 








* 




MC68000 EDN BENCHMARK F 








* 
* 




BIT ARRAY TEST, SET, AND RESET 








* 


ATTRIBUTES: * 16 MEGABYTE ADDRESSING RANGE 


9 








* 




* POSITION INDEPENDENT 


10 








* 




* REENTRANT 


11 








* 






12 








* 


INPUT 


: 


13 








* 


D0 


- FUNCTION CODE A0 - BIT ARRAY BASE ADDRESS 


14 








* 


Dl 


- BIT SUBSCRIPT INDEX 


15 








* 






16 








* 


OUTPUT I 


17 








* 


D2 


- RETURN CODE 


18 








* 






19 








* 


ALL 


OTHER REGISTERS ARE TRANSPARENT OVER THIS ROUTINE 


20 








* 






21 








* 




LINES: 15 


22 








* 




BYTES: 36 


23 








* 






24 








* 


MC68000L10 BENCHMARK TIME: 70.200 MICROSECONDS 


25 








* 






26 














27 














28 








* 


BIT TEST, SET, RESET SUBROUTINE 


29 





00000000 


2401 


BIT 


MOVE.L D1,D2 COPY BIT INDEX OVER 


30 





00000002 


E68A 






LSR.L #3,D2 DIVIDE BY 8 FOR BYTE ADDRESS 


31 





00000004 


5540 






SUB #2,D0 OFFSET FUNCTION CODE DOWN 2 


32 





00000006 


670C 






BEQ SET BRANCH IF 2 TO SET 


33 





00000008 


5340 






SUB #1,D0 DOWN ANOTHER 


34 





0000000A 


6710 






BEQ RESET BRANCH IF 3 TO RESET 


35 








* 


TEST 




36 





0000000C 


03302800 






BTST D1,(A0,D2.L) CODE NOT 2 OR 3 - TEST BIT 


37 





00000010 


56C2 






SNE D2 SET RETURN CODE SAME AS BIT 


38 





00000012 


4E75 






RTS RETURN TO CALLER 


39 








* 


SET 




40 





00000014 


03F02800 


SET 


BSET D1,(A0,D2.L) CODE 2 - SET BIT 


41 





00000018 


56C2 






SNE D2 SET RETURN CODE FOR PREVIOUS SETTING 


42 





0000001A 


4E75 






RTS RETURN TO CALLER 


43 








* 


RESET 




44 





0000001C 


03B02800 


RESET 


BCLR D1,(A0,D2.L) CODE 3 - CLEAR BIT 


45 





00000020 


56C2 






SNE D2 SET RC ONE OR ZERO, SAME AS PREVIOUS 


46 





00000022 


4E75 






RTS RETURN TO CALLER 


47 














48 












END 


****** 


TOTAL ERRORS — 
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1 Exampl 


e F: Bit array manipulation routines 1 






1 Arguments: I 








F 


:» R0 IFunction code - possible vaues are:! 






FL 


:- RL0 








FH 


:- RH0 








TSTCODE :- 1 I Test 


the bit! 






SETCODE :- 2 ISet the bit to 1! 






RESCODE :« 3 1 Reset the bit to 0! 






N 


:■ Rl (Index (from zero) of desired bit! 






Al 


:- R2 1 Address of bit array (RR2 for seg) 1 






A10FF 


:■ R2 IR3 for segmented I 






RC 


:« R3 (Return arg: set to value of desired bit! 






Workspace for the routine:! 








BYTNUM 


:« RC IByte 


offset of desired bit in Al array! 






CURBYTE 


:■ FH J Temp 


home of byte containing the bit! 




0000 A113 


BITMANi 


LD BYTNUM, N 


! Compute byte offset of 1 




0002 B339 




SRA BYTNUM, #3 


! desired byte (divide by 8) ! 




0004 FFFD 










0006 8132 




ADD Al OFF, BYTNUM 


IPoint at desired byte ! 




0008 2020 




LDB CURBYTE, 8A1 


IGet the byte! 




000A 2601 




BITB CURBYTE, N 


ITest the bit! 




000C 0000 










000E E607 




JR Z, NOTSET 






0010 BD31 




LDK RC,*1 


ISet-indicate in RC! 




0012 AA82 




DECB FL,#RESCODE 


IShould it be cleared?! 




0014 9E0E 




RET NE 


1 No, exit ! 




0016 2201 




RESB CURBYTE, N 


! Yes, do it 1 




0018 0000 










001A 2E20 




LDB §A1, CURBYTE 






001C 9E08 




RET 






001E BD30 


NOTSET: 


LDK RC,#0 


IClear-indicate in RC! 




0020 AA81 




DECB FL,#SETCODE 


IShould it be set?! 




0022 9E0E 




RET NE 


I No, exit I 




0024 2401 




SETB CURBYTE, N 


1 Yes, do it ! 




0026 0000 










0028 2E20 




LDB §A1, CURBYTE 


ISave changed byte ! 




002A 9E08 




RET 




Continued on pg 229 
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BENCHMARK H- 


-68000 


80 

81 

82 

83 

84 
85 
86 

87 

88 
89 
90 


0000004E 234A0004 
00000052 236A00080008 
00000058 25490008 
0000005C 24690008 
00000060 25490004 


MOVE . L 
MOVE.L 
MOVE.L 
MOVE . L 
FINISHL MOVE.L 


A2,NEXT(A1) SET NEW. NEXT TO CURRENT 
PREV(A2),PREV(A1) SET CURRENT EARLIER TO NEW.PREV 
A1,PREV(A2) SET CURREN.PREV TO NEW 
PREV(A1),A2 LOAD CURRENT EARLIER ADDRESS 
A1,NEXT(A2) SET EARLIER. NEXT TO NEW 


00000064 4CDF0403 
00000068 4E75 


* RESTORE REGISTERS AND RETURN 
FINISH MOVEM.L (SP) +,D0/D1/A2 
RTS 


RESTORE REGISTERS 
RETURN TO CALLER 




END 






****** 


TOTAL ERRORS — 
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(Example H 


• Insertion i 


n a Doubly Linked list I 




ADLEN := 


2 




(Number of bytes in an address 












(4 for segmented operation) 


! 


(Arguments 


: ! 








LISTCB := 


R12 




(Address of list control block 












(RR12 for segmented) 


! 


(Format of 


list 


control 


block: 




HEADF := 







lAdr of the list "head" (first 


entry) ! 


TAILF := 


ADLEN 


(Adr of "tail" (last entry)! 




NUMF := 


TAILF+ADLEN 


(Number of entries in list! 




NEWENTRY:= 


R10 




!Address of entry to be inserted 










(RR10 for segmented) 


! 


NEWOFF : = 


R10 




lOffset portion of address! 




(Format of 


an e 


ntry 






KEYF : = 







!Key portion of entry! 




LKEY := 


4 




(Number of bytes in a key! 




NEXTF := 


LKEY 




! Pointer to "next" entry ! 




PREVF : = 


NEXTF+ADLEN 


IPointer to "previous" entry! 




(Working s1 


torage for routine: I 




KEY 


: = 


RRO 








PTRS 


: = 


R2 




IFirst of registers for NEXT ar 


d PREV! 


NEXTAD := 


R2 




! (RR2 for segmented)! 




PREVAD : = 


R3 




! (RR4 for segmented)! 




NPTRS := 


ADLEN 


IRegisters in the block (2«ADLEN/2)! 


NUM 


: = 


R4 




! "Number of entries" from LISTCB ! 










! (R6 for segmented) ! 




WK3 


: s 


RO 








NW3 


:s 


NPTRS+3 






0000 


ABF9 




LISTIN: 


DEC SP,#2«NW3 




0002 


1CF9 






LDM 6SP,WK3,#NW3 


ISave registers used ! 


0004 


0004 










0006 


14A0 






LDL KEY,§NEWENTRY 


!Get the new entry's key 


0008 


31C4 






LD NUM,LISTCB(#NUMF) 


1 Count the new entry! 


OOOA 


0004 










0O0C 


A940 






INC NUM 




000E 


33C4 






LD LISTCB(#NUMF),NUM 




0010 


0004 










0012 


BD30 






LDK PREVAD, #0 


(Zap PREVAD pointer! 


0014 


0B04 






CP NUM,#1 


IFirst entry?! 


0016 


0001 










0018 


EE05 






JR NE, NOTFRST 


! no-go scan list! 


001A 


BD20 






LDK NEXTAD, #0 


! yes - zap "next" ptr! 


001C 


2FCA 






LD §LISTCB,NEWENTRY 


!Set LISTCB "head" ptr! 


001E 


33CA 






LD LISTCB(#TAILF),NEWENTRY 


!Set LISTCB "tail" ptr! 


0020 


0002 










0022 


E817 






JR UPNEW 


(Update new entry's ptrs 


0024 


21 C2 




NOTFRST 


:LD NEXTAD, 0LISTCB 


Unit "next" for scant 


0026 


1020 




SCANLP: 


CPL KEY,0NEXTAD 


ICompare keys! 


0028 


E906 






JR GE, TRYNEXT 


! not the place! 


002A 


8D34 






TEST PREVAD 


(Insert here. Head?! 


002C 


EEOE 






JR NZ, UPMID 


! no - update and exit 


002E 


2FCA 






LD §LISTCB,NEWENTRY 


! yes - adjust LISTCB! 


0030 


332A 






LD NEXTADUPREVF),NEWENTRY 


lUpdate prev's "next"! 


0032 


0006 










0034 


E80E 






JR UPNEW 


(Update new entry's ptrs 


0036 


A123 




TRYNEXT 


:LD PREVAD, NEXTAD 


(Next in listl 


0038 


3132 






LD NEXTAD, PREVAD(#NEXTF) 




003A 


0004 










003C 


8D24 






TEST NEXTAD 


(New tail?! 


003E 


EEF3 






JR NZ, SCANLP 


! no - keep looking! 


0040 


333A 






LD PREVAD(#NEXTF),NEWENTRY 


I yes - set prev's "nxt" 


0042 


0004 










0044 


33CA 






LD LISTCB(#TAILF),NEWENTRY 


!Set LISTCB "tail" ptr! 


0046 


0002 










0048 


E804 






*JR UPNEW 


(Update new entry's ptrs 


004A 


332A 




UPMID: 


LD NEXTAD UPREVF) ,NEWENTRY 


(Update next's "prev"! 


004C 


0006 










004E 


333A 






LD PREVAD(#NEXTF),NEWENTRY 


(Update prev's "next"! 


0050 


0004 










0052 


A9A3 




UPNEW: 


INC NEWENTRY, #LKEY 


IWrite entry pointer! 


0054 


1CA9 






LDM §NEWENTRY,PTRS,#NPTRS 




0056 


0201 










0058 


1CF1 






LDM WK3,§SP,#NW3 




005A 


0004 










005C 


A9F9 






INC SP,#2«NW3 


IRestore registers I 


005E 


9E08 






RET 
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96 


0000008A 


48D3000F 




MOVEM.L 


D0-D3, (A3) 


AND 


97 


0000008E 


48D000F0 




MOVEM.L 


D4-D7,(A0) 


REC(J) 


98 


00000092 


2209 




MOVE . L 


A1,D1 


Dl <- R 


99 


00000094 


240B 




MOVE . L 


A3,D2 


D2 <- J 


100 


00000096 


9282 




SUB.L 


D2 f Dl 


Dl <- R-J 


101 


00000098 


9488 




SUB.L 


A0,D2 


D2 <- J-L 


102 


0000009A 


B48E 




CMP.L 


A6,D2 


COMPARE (J-L) <= MSIZE 


103 


0000009C 


62C6 




BHI 


NEWLR0 


BRANCH IF NO 


104 


0000009E 


B28E 




CMP.L 


A6,D1 


COMPARE (R-J) <= MSIZE 


105 


000000A0 


62D8 




BHI 


NEWLR1 


BRANCH IF NO 


106 


000000A2 


4CDF0300 




MOVEM.L 


(SP)+,A0/A1 


POP NEXT L AND R FROM STACK 


107 


000000A6 


2008 




MOVE . L 


A0,D0 


TEST IF STACK IS EMPTY 


108 

109 

110 


000000A8 


6600FF6C 




BNE 


SORT 


CONTINUE SORT IF NOT EMPTY 






* FALL 


INTO INSERTION SORT AS ALL SUBFILES BELOW OR EQUAL M RECORDS 


112 






* 




INSERTION SORT PHASE 


113 






* 








114 






* REGISTER USE: 


D0 - LOOP CONTROL 


A0 - REC(I) 


115 






* 




Dl - COUNTER AND SWAP 


REGISTER Al - REC(J) 


116 






* 




D2/D4 - SWAP REGISTERS A2/A3 - WORK REGISTERS 


117 






* 




D5/D7 - "V" SAVE REGISTERS A4 - REC(J-l) 


118 






* 






A5 - "V" SAVE REGISTER 


119 






* 






A6 - FRAME POINTER 


120 






* 








121 






* 


NOTE: STACK SPACE IS RESERVED 


FOR "V" KEY COMPARE RECORD COPIES 


122 






* 








123 














124 


000000AC 


4CDF0101 




MOVEM.L 


(SP)+,D0/A0 


RELOAD RECORD COUNT AND TOP RECORD 


125 


000000B0 


4E56FFF0 




LINK 


A6,#-ENTRYLEN 


ALLOCATE "V" KEY COPY AREA ON STACK 


126 
127 
128 


000000B4 


5540 




SUB 


#2,D0 


D0 RANGES FROM N-2 THROUGH 


000000B6 


41E8FFF0 


LOOPOUT LEA 


-ENTRYLEN(A0) ,A0 


I <- 1-1 


129 


000000BA 


45E80003 




LEA 


KEY(A0) ,A2 


A2 -> KEY(i) 


130 


000000BE 


47E80013 




LEA 


ENTRYLEN+KEY(A0) ,A3 


A3 -> KEY(I+1) 


131 


000000C2 


7206 




MOVE . L 


#KEYLEN-1,D1 


LOOP COUNTER FOR COMPARE 


132 


000000C4 


B50B 


CMPII1 


CMP.B 


(A3)+,(A2) + 


COMPARE KEY(I)-KEY(I+1) 


133 


000000C6 


56C9FFFC 




DBNE 


D1,CMPII1 


LOOP WHILE EQUAL 


134 
135 
136 


000000CA 


6332 




BLS 


ENDIF 


BRANCH IF KEY(I) <= KEY(I+1) 


000000CC 


4CD020E0 




MOVEM.L 


(A0) ,D5-D7/A5 


V <- REC(I) 


137 


000000D0 


48D700E0 




MOVEM.L 


D5-D7, (SP) 


AND ON STACK FOR KEY COMPARE 


138 


000000D4 


43E80010 




LEA 


ENTRYLEN(A0) ,A1 


Al -> REC(J) = REC(I+1) 


139 
140 
141 


000000D8 


2848 




MOVE.L 


A0,A4 


PRIME A4 -> REC(J-l) 


000000DA 


4CD1001E 


LOOPIN 


MOVEM . L 


(Al) ,D1-D4 


TEMP <- REC(J) 


142 


000000DE 


48D4001E 




MOVEM.L 


D1-D4, (A4) 


REC(J-l) <- TEMP 


143 


000000E2 


2849 




MOVE . L 


A1,A4 


A4 -> NEXT REC(J-l) 


144 


000000E4 


43E90010 




LEA 


ENTRYLEN(Al) ,Al 


J = J+l 


145 


000000E8 


45EF0003 




LEA 


KEY(SP) ,A2 


A2 -> KEY(V) 


146 


000000EC 


47E90003 




LEA 


KEY(Al) ,A3 


A3 -> KEY (J) 


147 


000000F0 


7206 




MOVE . L 


#KEYLEN-1,D1 


LOOP COUNTER IN Dl 


148 


000000F2 


B50B 


CMPVJ 


CMP.B 


(A3)+,(A2)+ 


COMPARE KEY (V) -KEY (J) 


149 


000000F4 


56C9FFFC 




DBNE 


Dl, CMPVJ 


LOOP WHILE EQUAL 


150 
151 
152 
153 
154 
155 
156 


000000F8 


62E0 




BHI 


LOOPIN 


IF KEY(V) > KEY(J) CONTINUE LOOP 


000000FA 


48D420E0 




MOVEM.L 


D5-D7/A5, (A4) 


REC(J-l) <- V 


000000FE 


51C8FFB6 


ENDIF 


DBRA 


D0, LOOPOUT 


CONTINUE LINEAR INSERT 


00000102 


4E5E 




UNLK 


A6 


FREE AND RESTORE STACK 


157 


00000104 


4CDF7FFF 




MOVEM.L 


(SP)+,D0-D7/A0-A6 


RESTORE REGISTERS 


158 
159 


00000108 


4E75 




RTS 




RETURN TO CALLER 


160 
161 








END 







BENCHMARK I— Z8000 



lExample I: Quicksort/Insertion Sort! 



(Arguments 

N 

M 

REC 

RECOFF 

RECSEG 



! 

RO 

R1 

RR2 

R3 

RH2 



Working 

SCRL 

SCR1 

SCR2 

BIGM 

ADR 

I 

J 

L 

U 

ITAD 



regist 
= RRO 
= RO 
= R1 
= SCRL 
= RR4; 
= RR6; 
= RR8; 
= RR10 
= RR12 



! Number of records ! 
! Changeover point ! 
lArray base ! 



ers I 
IScratch borrowed from argument registers ! 



ADRHH 

IHI 

JHI 
;LHI 
;UHI 



= RH4; 

= R6; 

= R8; 

= R10; 

= R12: 



ADRHL 

ILO 

JLO 

LLO 

ULO 



RL4; ADRL := R5 

R7 

R9 

R11 

R13 



ADRL JAddress of I-item I 
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JTAD := 


LLO 


lAddre 


3S of J-item 1 




PIVOT := 


SCRL 








PIVHI := 


SCR1 








PIVLO := 


SCR2 








I Temporary 


registers f 


>r item moving ! 




DEST := 


LLO 








SRCE := 


ADRL 








!Other constants ! 






ESIZE := 


16 


IBytes 


per record! 




KEYOFF := 


3 


Ilndex 


in record of first byte 


of key 1 


KEYBYTES:s 


7 


IBytes 


per key! 




0000 ABFF 




SORT: 


DEC SP,#16 




0002 ABFB 






DEC SP,012 




0004 1CF9 






LDM §SP,R0,#14 


ISave all registers ! 


0006 000D 










0008 A10D 






LD ULO,N 


! Number of records ! 


OOOA B1CA 






EXTS U 




OOOC 190C 






MULT U, RESIZE 


!Mult by size of records ! 


OOOE 0010 










0010 140A 






LDL L,#0 


IZero lower limit to start ! 


0012 0000 










0014 0000 










0016 91FC 






PUSHL §SP,U 




0018 1900 






MULT BIGM, 0ESIZE 


lAdjust cutoff for record size 


001A 0010 










001C 91F0 






PUSHL §SP,BIGM 




001 E DFB7 






CALR QUICK 




0020 95F0 






POPL BIGM,§SP 




0022 95F6 






POPL I,§SP 




0024 1206 






SUBL I,#ESIZE 




0026 0000 










0028 0010 










002A 9464 




INSORT: 


LDL ADR, I 




002C 1604 






ADDL ADR,#ESIZE 




002E 0000 










0030 0010 






ICALR ADCOMP! 




0032 8135 






ADD ADRL,RECOFF 




0034 1604 






ADDL ADR,#KEYOFF 




0036 0000 










0038 0003 










003A 9440 






LDL PIVOT, ADR 


IPIVOT is adr of key of A(I+1) ! 


003C DF7D 






CALR CPPI 




003E EF2F 






JR UGE, END1 


!If A(I+1)>=A(I), end block ! 


0040 ABFF 






DEC SP, RESIZE 




0042 8D08 






CLR PIVHI 




0044 A1F1 






LD PIVLO, SP 


IPIVLO has adr of V on stack ! 


004b 1600 






ADDL PIVOT, tfKEYOFF 


IPIVOT points to key in V ! 


0048 0000 










004A 0003 










004C A1FB 






LD DEST,SP 




004E 9464 






LDL ADR, I 
ICALR ADCOMP! 


IADRL is source address ! 


0050 8135 






ADD ADRL,RECOFF 




0052 BDA8 






LDK R10,#(ESIZE/2) 




0054 BB51 






LDIR §DEST,§SRCE,R10 


ISave a(I) on stack ! 


0056 OABO 










0058 9468 






LDL J, I 




005A 1608 






ADDL J, RESIZE 


!J = I + 1 ! 


005C 0000 










005E 0010 










0060 9484 




AGN2: 


LDL ADR, J 




0062 1204 






SUBL ADR, RESIZE 


!ADR = J - 1 ! 


0064 0000 










0066 0010 






ICALR ADCOMP! 




0068 8135 






ADD ADRL,RECOFF 




006A 944A 






LDL L,AD'R 


!L s address of A(J-1) I 


006C 9484 






LDL ADR, J 
ICALR ADCOMP! 




006E 8135 






ADD ADRL,RECOFF 




0070 BDA8 






LDK R10,#(ESIZE/2) 




0072 BB51 






LDIR §DEST,§SRCE,R10 


!A(J-1) = A(J) ! 


0074 OABO 










007.6 1608 






ADDL J, RESIZE 


!J = J ♦ 1 ! 


0078 0000 










007A 0010 










007C DF9B 






CALR CPPJ 




007E E401 






JR OV, ENDLAST 




0080 EFEF 






JR UGE,AGN2 




0082 9484 




ENDLAST 


:LDL ADR, J 




0084 1204 






SUBL ADR, RESIZE 


!ADR = J - 1 ! 


0086 0000 










0088 0010 






ICALR ADCOMP! 




008A 8135 






ADD ADRL,RECOFF 




008C 944A 






LDL L,ADR 




008E 9404 






LDL ADR, PIVOT 




0090 1204 






SUBL ADR,#KEYOFF 


IADR s address of V again I 


0092 0000 










0094 0003 










0096 BDA8 






LDK R10,#(ESIZE/2) 




0098 BB51 






LDIR §DEST,eSRCE,R10 


IAU-1) = V I 
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009A OABO 
009C A9FF 
009E 1206 
00A0 0000 
00A2 0010 
00A4 9C68 
00A6 EEC1 
00A8 1CF1 
OOAA OOOD 
OOAC A9FF 
OOAE A9FB 
OOBO 9E08 



00B2 94 C4 
00B4 92A4 
00B6 9004 
00B8 9E02 
OOBA 91F0 



OOBC 94A4 

OOBE 8135 
OOCO 1604 
00C2 0000 
00C4 0003 
00C6 9440 
00C8 94A6 
OOCA 94C8 
OOCC 1608 
OOCE 0000 
OODO 0010 
00D2 91 FA 
00D4 91FC 
00D6 DFD7 
00D8 DFD1 
OODA 9484 

OODC 8135 
OODE 944A 
OOEO 9068 
00 E2 E202 
00E4 DFC5 
00 E6 E8F7 
00E8 DFC4 
OOEA 95FC 
OOEC 95FA 
00 EE 9486 
OOFO 94C8 
00F2 946C 
00F4 120C 
00F6 0000 
00F8 0010 
OOFA 1606 
OOFC 0000 
OOFE 0010 

0100 9480 

0102 9260 

0104 9404 

0106 94C0 

0108 92 AO 

010A 9040 

010C E204 

01 OE ADA6 

0110 ADB7 

0112 ADC8 

0114 ADD9 

0116 95F0 

0118 ABF7 

011A 1CF9 

01 1C 0603 

01 1E D037 

0120 1CF1 

0122 0A03 

0124 A9F7 

0126 D03B 

0128 9E08 



INC SP, RESIZE 
SUBL I, RESIZE 



TESTL I 

JR NZ.INSORT 
LDM R0,gSP,#14 

INC SP,#16 
INC SP,#12 
RET 

ISubroutine Quicksort - after C. A. R. Hoare 
CALL QUICK with BASE = array address 

U = offset of upper limit 
L = offset of lower limit 
Semi-sorts elements at offsets between L and U (inclusive). 
The 23-bit integers L and U are in the range to 8,388,607. 



IRestore registers ! 



(compute subfile size ! 

IReturn if subfile is <= M long ! 



I 

QUICK: LDL ADR,U 

SUBL ADR,L 

CPL ADR,BIGM 
RET LE 

PUSHL §SP,BIGM 

I Partition array segment between offsets L and U (inclusive) 
around a pivot element with index J. Returns the ranges: 

(L,J-1) in L,U 

(J+1,U) in I, J 
! 
PART: LDL ADR,L IADR = L ! 

ICALR ADCOMP! IADR = actual address of a(L) ! 

ADD ADRL,RECOFF 

ADDL ADR,#KEYOFF ladd in offset of key within record ! 



LDL PIVOT, ADR 
LDL I,L 
LDL J,U 
ADDL J, RESIZE 



JPIVOT = actual address of pivot ! 



!J = J+1 I 



LPIs 



PUSHL §SP,L 

pushl esp,u 

CALR UPI 
CALR DOWNJ 
LDL ADR, J 
ICALR ADCOMP! 
ADD ADRL,REC0FF 
LDL L,ADR 
CPL J, I 

JR LE,M0VPIV 
CALR EXCHIJ 
JR LPI 
MOVPIV: CALR EXCHJP 
POPL u,esp 

POPL L,§SP 

LDL I, J IPut J in RR4 ! 

LDL J,U IPut U in RR6 I 

LDL U,I ICopy of J into U also! 

SUBL U,#ESIZE ! L,U = (L,J-1) ! 



ADDL I, RESIZE ! I, J - (J+1-,U) ! 



I Put shorter range in L,U, longer in I, J ! 



ISAVE L,U ! 

line I until a(I) >= pivot value! 

!Dec J until a(J) =< pivot value or J=<I 



!L = actual address of a(J) ! 
ICompare J and I ! 
!J <= I, exchange a(J) and pivot ! 
lExchange a(I) and a(J) values! 

JExchange a(J) and pivot values! 

IRestore L,U ! 



ISCRL = U-L for first range! 



ISave first U-L ! 

ISCRL = U-L for second range! 



ICompare lengths! 
IDone if second U-L 



< first U-L ! 



SHORT: LDL SCRL,J 

SUBL SCRL,I 

LDL ADR,SCRL 

LDL SCRL,U 

SUBL SCRL,L 

CPL SCRL,ADR 
JR LE,Q1 

EX IHI,LHI 

EX ILO,LLO 

EX JHI,UHI 

EX JL0,UL0 
Q1: POPL BIGM,eSP 

DEC SPOFF,#8 

LDM §SP,IHI,#4 

CALR QUICK I Recursive call to sort shorter range! 
LDM LHI,§SP,#4 IRestore longer range into L,U I 

INC SPOFF,#8 
CALR QUICK 
RET 



ISave I, J = longer (L,U) range! 



(Recursive call to sort longer range! 



(Subroutines for moving I and J 

CALL UPI: Increment I until a(I) >= pivot value 

CALL DOWNJ: Decrement J until a(J) =< pivot value 

I 

UPI: ADDL I,#ESIZE Ilncrement I I 
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012C 0000 






012E 0010 






0130 DFF7 




CALR CPPI ICompare pivot value with a(D! 


0132 9E04 




RET OV IOV = 1 says pivot = a (I) ! 


Q134 9E07 




RET ULT IReturn if pivot value =< a(D! 


0136 E8F9 




JR UPI 


0138 1208 


DOWNJ : 


SUBL J,#ESIZE IDecrement J ! 


013A 0000 






013C 0010 






01 3E DFFC 




CALR CPPJ 


0140 9E0F 




RET UGE IReturn if pivot >= A(J) ! 


0142 E8FA 




JR DOWNJ 




IPlvot 


and exchange subroutines 




CALL 


CPPI - compare pivot value and a(I). Set FLAGS. 




CALL 


EXCHJP - exchange a(J) and pivot values 




CALL 


EXCHIJ - exchange a(I) and a(J) values 




Register uses as for PART 






U scratch 






ADR calling arg for and address returned by ADCOMP 




! 


L actual address of a(J) for exchange routines. 


0144 9464 


CPPI: 


LDL ADR, I IADR = 11 


0146 E801 




JR IJM 


0148 9484 


CPPJ: 


LDL ADR, J IADR = Jl 




IJM: 


I CALR ADCOMP! IADR = adr of comparand! 


014A 8135 




ADD ADRL,RECOFF 


014C 160M 




ADDL ADR,#KEYOFF 


014E 0000 






0150 0003 






0152 940A 




LDL L, PIVOT !L = actual pivot address ! 


0154 BDC7 




LDK UHI,#KEYB,YTES iNumber of bytes in key ! 


0156 BA56 




CPSIRB eDEST,eSRCE,UHI,NE 


0158 OCBE 






015A 9E08 




RET 


015C 9464 


EXCHIJ 


LDL ADR, I 

I CALR ADCOMP! 


015E 8135 




ADD ADRL,RECOFF 


0160 E804 




JR EXCH lExhange a(I) and a(J) ! 


0162 9404 


EXCHJP 


LDL ADR, PIVOT 


0164 1204 




SUBL ADR,#KEYOFF !ADR = address of a(J) I 


0166 0000 






0168 0003 






016A BDC8 


EXCH: 


LDK UHI,#(ESIZE/2) lRecord word count ! 


016C 215D 


EXLOOP. 


LD UL0,§ITAD IPick up pivot or A(I) ! 


016E 2DBD 




EX UL0,§JTAD lExchange with A(J) 1 


0170 2F5D 




LD §ITAD,UL0 ! a(I) or pivot = a(J)I 


0172 A951 




INC ADRL,#2 
INC LL0,#2 


0174 A9B1 




0176 FC86 




DJNZ UHI, EXLOOP I And repeat for whole record ! 


0178 9E08 




RET 


017A ACC4 


ADCOMP 


EXB ADRHH,ADRHL IMove high index to seg field ! 


017C 8135 




ADD ADRL,RECOFF !Add offset of REC to low index! 


017E B424 




ADCB ADRHH,RECSEG !Add seg of REC (with C) to high 
! part of index ! 


0180 9E08 




RET 







BENCHMARK K-LSI-11/23 




1 




•TITLL BENCHMARK K 






2 




.IDENT /OCT. 23/ 






3 
4 

5 
6 

7 
9 




.ENABL LC 








; BOOLEAN MATRIX TRANSPOSE 


1 






i 

; Transpose a tightly-packed 


bit matrix 




9 




; Arguments are passed on tn< 


stack. 




10 




; Offsets assume 14(8) bytes 


used for saving registers on stack. 


11 




f 






12 


000016 


N » 16 




j size of matrix 


1? 


000020 


Al = 20 




; pointer to a word of storage 


14 


000022 


A2 = 22 




; bit offset of start of matrix 


15 










16 000000 




ONTRACE:: 






17 000000 




RMT! ! 






18 










19 




; save registers 






20 




; 






21 000000 


010046 


MOV RO, -(SP) 






22 000002 


010146 


MOV Rl, -(SP) 






23 000004 


010246 


MOV R2, -(SP) 






24 000006 


010346 


MOV R3, -(SP) 






25 000010 


010446 


MOV R4, -(SP) 






26 000012 


010546 


MOV R5, -(SP) 






27 








Continued on pg 256 
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69 

70 
71 

72 
73 

74 

75 
76 
77 



0000003C B883 
0000003E 66D6 



00000040 51CAFFCC 



00000044 4CDF0738 
00000048 4E75 



BENCHMARK K— 68000 



CMP.L 
BNE 


D3,D4 
INNRLP 


DBRA 


D2,OUTRLP 


MOVEM.L 
RTS 


(SP)+,D3-D5/A0-A2 



TEST FOR MEET AT DIAGONAL 
BRANCH IF NOT FOR ANOTHER SWAP 



LOOP UNTIL PAST 'N' 



RESTORE REGISTERS 
RETURN TO CALLER 
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I Example 


K: Boolean Matrix Transpose I 




I Arguments: 1 






NX 


= RO 


IDimension of Matrixl 




A2 


= Rl 


IBit (0<=A2O15) at which 


matrix begins in All 


A1X 


* R2 


lAddress of first word of 


Matrixl 


IWorking 


storage for the routine:! 




WK5 


= R4 






NW5 


* 9 






IJBYTE 


= RH4 


I Byte containing a (I, J) 1 




JIBYTE 


= RL4 


IByte containing a (J, I) I 




TWOBITS 


«= RH5 


IHolds both bit valuesl 




IJBP 


■ R6 


IBit number of a (I, J) I 




J IBP 


■ R7 


IBit number of a(I f J) ! 




IJPTR 


= R8 


lAddress of IJ byte! 




JIPTR 


■ R9 


lAddress of JI byte! 




IJBX 


= RIO 


1IJBP for outer loop! 




JIBX 


= Rll 


UIBX for outer loopl 




LPCNT 


- R12 


I Counter for outer loopl 




ILong re< 


jisters 


for one-step loads! 




BPL 


= RR6 






OFFL 


- RR8 






BXL 


■ RR10 








ICode for Boolean matrix transpose 


0000 ABFF 


BMTRAN: DEC SP, #16 




0002 ABF1 




DEC SP,#2*NW5-16 




0004 1CF9 




LDM §SP,WK5,#NW5 


ISave registers 1 


0006 0408 








0008 AHA 




LD IJBX r A2 


I I, J - J, I - 1,1 I 


0OOA AilB 




LD JIBX,A2 




000C A10C 




LD LPCNT, NX 


lExecute outer loop 1 


000E ABCO 




DEC LPCNT 


1 N-l times 1 


0010 A9A0 


OUTLP: INC IJBX 


1 Increment row and I 


0012 810B 




ADD JIBX, NX 


1 column for outer loop 1 


0014 94A6 




LDL BPL, BXL 


Unit inner loop ptrs 1 


0016 9468 


INLP 


: LDL OFFL, BPL 


{Compute byte addresses I 


0018 B389 




SRA IJPTR, #3 




001A FFFD 








001C 8128 




ADD IJPTR, A1X 




001E B399 




SRA JIPTR, #3 




0020 FFFD 








0022 8129 




ADD JIPTR, A1X 




0024 8255 




SUBB TWOBITS, TWOBITS 


Unit bit keeper! 


0026 209C 




LDB JIBYTE, § JIPTR 


IGet JI byte! 


0028 2607 




BITB JIBYTE, JIBP 


I Put bit into 1 


002A 0C00 








002C AE5E 




TCCB NZ, TWOBITS 


! TWOBITS, 1 


002E B254 




RRB TWOBITS 


1 sign bit 1 


0030 2084 




LDB IJBYTE, § IJPTR 


IGet IJ byte 1 


0032 2606 




BITB IJBYTE, IJBP 


IGet IJ bit 1 


0034 0400 








0036 AE5E 




TCCB NZ, TWOBITS 


1 TWOBITS, l.s.b. 1 


0038 B254 




RRB TWOBITS 


IReset V if & only if 1 


003A ECOF 




JR NOV, $3 


1 bits equal, done 1 


003C ED07 




JR PL,$1 


lis IJ bit set? 1 


003E 2407 




SETB JIBYTE, JIBP 


1 Yes, set JI 1 


0040 0C00 








0042 2E9C 




LDB §JIPTR, JIBYTE 


IStore JI byte 1 


0044 2084 




LDB IJBYTE, eiJPTR 


IReread in case IJPTR - JIPTR 1 


0046 2206 




RESB IJBYTE, IJBP 


IReset IJ 1 


0048 0400 








004A E806 




JR $2 




004C 2207 


$1: 


RESB JIBYTE, JIBP 


1 No, reset JI ! 


004E 0C00 








0050 2E9C 




LDB §JIPTR, JIBYTE 


IStore JI byte 1 


0052 2084 




LDB IJBYTE, § IJPTR 


IReread in case IJPTR - JIPTR 1 


0054 2406 




SETB IJBYTE, IJBP 


ISet IJ 1 


0056 0400 








0058 2E84 


$2: 


LDB 8IJPTR, IJBYTE 


IStore IJ byte! 


005A 8106 


$3: 


ADD IJBP, NX 


1 Increment row and column ! 


005C A970 




INC JIBP 


1 for inner loopl 


005E 8B76 




CP IJBP, JIBP 


lAt the diagonal yet? 1 


0060 EEDA 




JR NE,INLP 


1 No, keep swapping ! 


0062 FCAA 




DJNZ LPCNT, OUTLP 


1 Yes, do NEXT outer loop ! 


0064 1CF1 




LDM WK5,@SP,*NW5 




0066 0408 








0068 A9FF 




INC SP,#16 




006A A9F1 




INC SP,#2*NW5-16 


{Restore registers 1 


006C 9E08 




RET 
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Some fundamental constraints on micro- 
processor peripheral families have always 
existed, but some of the more severe con- 
straints In the present 16-bit environment 
will be worse In future 32-bft environments. 
One of these restrictions Is the number of 
signal lines available — usually correspond- 
ing to the number of pins on a package. 
Present packaging technology for mass- 
produced parts allows up to 64 pins, which 
Is sufficient for a 16-bft microprocessor 
with an unmultlplexed address/data bus or a 
32-blt microprocessor with a multiplexed 
address/data bus. Unfortunately, control of 
these wide buses uses most of the pins 
available with current packaging, so any 
device controlling the bus cannot have a 
wide, Independent data path. 

The key word here Is "Independent." It is 
certainly possible to design a device that 
could operate a local bus and, when neces- 
sary, switch modes to control a global bus. 
This mode of operation for multiple 
processor-type devices Is Inferior for 
several reasons. First, when the buses are 
linked, other processes experience longer 
delays in being serviced. Second, an archi- 
tecture that allows multiple-processor 
devices access to most memory In the system 
Is a difficult one in which to assure data 
and system Integrity. A third difficulty is 
simply the number of devices necessary to 
link the buses. Typical implementations 
require six to eight packages. 

A significant observation Is that the only 
commercially available I/O devices that 
Incorporate a DMA-type function are serial 
input/output devices and CRT controllers. 
Only these applications allow enough pins to 
properly implement the DMA function. 

Fortunately, the same technology that 
enables the integration of 16- and 32-bit 
microprocessors also allows the integration 
of considerable intelligence and some buffer 
memory in the peripheral device. This is a 
very powerful combination, especially In 
conjunction with highly Integrated CPU/DMA 



combinations, and can be used to link mul- 
tiple local buses to a main system bus at 
high speed and with little overhead. 

Local buses are, In general, a very effec- 
tive way to Improve over a I I system per- 
formance. They allow significant parallel 
processing to occur and can Improve system 
reliability by partitioning the tasks to 
make Interference between processes less 
likely. Many of the problems with linking 
multiple buses can be avoided by adding 
buffer memory between the buses. In many of 
the new-generation I/O devices, this buffer 
memory can be included on the integrated 
circuit Itself. 

An example of the power of these techniques 
is the construction of a high-speed 
para I lel/serlal front-end processor for a 
high-end microcomputer system (Figure 1). 

The key element In this system is the Z8038 
FIO (FIFO Input/Output) device. This is a 
128x8 FIFO buffer that has the necessary 
Intelligence and flexibility to Interface to 
a wide variety of microprocessors. It also 
has the ability to Interrupt under a variety 
of conditions and can bypass the data FIFO 
by a separate path to pass control and 
status information from one processor to 
another. 

Information is passed from one processor to 
the other on a message basis. A typical 
transfer begins with the main system 
processor sending a control byte through the 
FIO to the local processor via the bypass 
register. This control communication typi- 
cally includes information about the data 
block length, the intended destination, and 
any other relevant parameters. At the same 
time, the main system DMA can be set up to 
begin trans fering data into the FIO. Either 
of the two DMA controllers in this system 
can be eliminated with little loss in per- 
formance if the CPU has block memory- to- I /0 
move instructions available, as In the Z80 
or Z8000. After initial setup of the FIO, 
the main system DMA is activated and quickly 
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fills the FIO»s data buffer, If the local 
system DMA has not yet been activated. This 
Is of little consequence, since the main 
system DMA will simply stop transfers when 
the RDY signal from the FIO goes Inactive. 
Similarly, If a block move Instruction Is 
being used Instead of a DMA, the FIO 
provides an "Interrupt-on-ful I" Interrupt, 
which allows the CPU to do other tasks until 
next Interrupted by the FIO. This second 
Interrupt occurs only when the contents of 
the FIO have been emptied to a predetermined 
programmable level. 



Similarly, on the local bus side of the FIO, 
the DMA will be active only when there Is 
data remaining In the FIO. To reduce the 
number of bus request cycles (or Interrupts 
In the case of a block move Instruction), 
the FIO can be programmed to request service 
from the local DMA only when the FIFO con- 
tains more than a certain programmable 
number of bytes. It will then transfer 
until the FIFO Is empty and continue this 
burst cycling until the end of the block. 

The combination of the block move Instruc- 
tions and the FIO Is more powerful than the 
replacement of the DMA function. Unlike the 
DMA, which, by requesting the system bus, 
places Itself at a higher priority than any 
Interrupt In the system, the block move 
Instructions can be Interrupted. This means 
that a high-priority Interrupt In either the 
local system or the main system can be 
serviced Immediately, even though the CPU Is 
Involved In a very high speed transfer of 



data through the FIO. If the Interrupt 
routine Is short, the other system may not 
even notice that the FIO was not being 
serviced for a short Interval. If the 
Interrupt Is longer, the fact that the FIFO 
may go empty Is of little consequence. An 
Interrupt on empty or an Inactive RDY line 
will serve to temporarily suspend service of 
the FIO at the local end. 



The FIO Is sufficiently flexible to Inter- 
face In four distinct applications: 

• To a multiplexed address/data bus micro- 
processor. 

• To an unmultlplexed address/data bus 
microprocessor. 

• With handshake lines to most types of 
para I lei -Interface I/O devices. 

• As a "high byte portion" of a 16- or 
32-blt link between buses. 



Figure 1 also shows the use of the FIO In 
a handshake application. One of the princi- 
pal advantages of the FIO in this configur- 
ation Is its ability to decrease interrupt 
hand I i ng overhead by more than two orders of 
magnitude, compared to the typical Interrupt 
handling with a parallel I/O device. For 
example, if interfaced to a line printer, 
the CPU would be interrupted once per line 
rather than once per character. Another 
capability of the FIO is its ability to 
recognize special characters (or bits In a 
character). It can Interrupt or stop DMA 
transfers when a special character comes 
through the FIFO, such as End of File. 
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The other device shown in the example is the 
Z8030 Z-SCC (Serial Communications Control- 
ler), This device can interface to nearly 
any type of serial device at up to a speed 
of 1 million bits per second. This 
includes all popular asynchronous formats 
and IBM Bisync (including Transparent mode), 
as well as the newer protocols such as X.21, 
X.25, SDLC, and HDLC. In its various modes, 
the Z-SCC can generate and check the two 
most popular CRCs (Cyclic Redundancy Codes), 
It also provides parity generation and 
checking and handles various lengths of 
characters. 

One major advantage of the Z-SCC over 
previous serial communications devices is 
its ability to do all clock recovery and 
generation for most types of encoding. 
Specifically, it can encode and decode NRZI 
as well as FM encoded data with transitions 
being interpreted as either Is or Os, It 
can also recover both clock and data from 
Manchester encoded data. 



In addition to its clock recovery capabili- 
ties, the Z-SCC has two timers for 
independent baud rate generation in each 
f ul I duplex channel • The timing sources can 
be the Z-SCC control clock, an external 
clock source, or the output of either of the 
on-chip crystal oscillators. This extreme 
flexibility in timing allows complete on- 
chip local loopback testing. An Auto-Echo 
mode is also provided for modem and link 
testing. 

In keeping with the trend of increased 
buffer memory, the Z-SCC has sufficient 
on-board buffering (four characters In the 
receiver) to allow time for interrupt 
response even at relatively high data rates. 
If DMA control becomes necessary for even 
faster data transfer, this can be accom- 
plished in a full duplex manner in both 
channel s. 
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Introduction In memory applications where the require- 

ments for byte-wide buffer storage are modest 
(2K to 32K bytes), the Z6132 offers a new con- 
cept in intelligent memory. The Z6132 features 
4K bytes of RAM in a byte- wide, 28-pin 
package that conforms to the 2716/2732 JEDEC 
standard. 

This application note discusses the basic 
features and operating modes of the Z6132, 
with application examples given for each of 
Zilog's microprocessors. In addition to a 
discussion of the interface requirements for the 
Z8TM, Z80® and Z8000TM CPUs, an application 
example describes the design requirements for 
interchanging the Z6132 with 2716/2732-type 
EPROMs. Each interface design includes logic 
and timing diagrams. Other Zilog documents 



that might be useful are referenced throughout 
the application note. 

The application note is divided into four sec- 
tions. The first section provides a general 
description of the Z6132 along with functional 
descriptions of each available type of memory 
operation. The self -refresh operation is 
discussed with the various refresh options 
available with the Z6132. The second section 
begins the application examples by providing 
interface circuitry for the Z80A CPU. The third 
and fourth sections provide interface circuitry 
and timing for the Z8002 and Z8 micro- 
processors. The section that discusses the Z8 
memory interface also treats the design criteria 
for interchanging the Z6132 with either 2716- 
or 2732-type EPROMs. 



General The Zilog Z6132 is a +5 V, intelligent, MOS 

Description dynamic RAM organized into 4096 8-bit words. 
of the Z6132 The Z6132 uses high-performance, depletion- 
load, double-poly, n-channel, silicon-gate 
MOS technology with a mixture of static and 
dynamic circuitry that provides a small 
memory cell and low power consumption. 
Internally, the Z6132 uses dynamic storage 
cells, but externally, the Z6132 functions as a 
static RAM because it controls and performs its 
own refresh. This eliminates the need for exter- 
nal refresh support circuitry and combines the 
convenience of a static RAM with the high 
density and low power consumption normally 
associated with dynamic RAMs. 

The Z6132 is particularly well suited for 
microprocessor and minicomputer applications 
where its byte-wide organization, self-refresh, 
and single power-supply voltage result in a 
reduced parts count and a simplified design. 
The Z6132 supports both multiplexed and non- 
multiplexed address and data li nes using the 
control signals Address Strobe (AS) and Data 
Strobe (DS) to latch address and data internal 
to the memory 'chip. The circuit is packaged in 
an industry-standard, 28-pm DIP and is pin 



compatible with the proposed JEDEC standard. 
The Z6132 conforms with the Z-BUS specifica- 
tion used by the new generation of Zilog 
microprocessors, the Z8 and Z8000. 

The Z6132 4K x 8 quasi-static RAM is 
organized as two separate memory-bit blocks. 
Each block has 128 sense amplifiers with 64 
rows of memory bits on each side. Both blocks 
have separate row address buffers and 
decoders. The two sets of row address . 
decoders are addressed either by the address 
inputs A1-A7 or by the internal 7-bit refresh 
counter. The least significant address input 
(Ao) selects one of the two blocks for external 
access. While the selected block performs a 
read or write operation, the other memory 
block uses the refresh counter address to 
refresh one row. Details of the self-refresh 
mechanism are discussed in the next section. 

A memory cycle starts when the rising edge 
of Address Clock (AC) clock s in Chip Select 
(CS), A , and Write Enable (WE). If the chip 
is not selected (CS is High), all other inputs 
are ignored until the next rising edge of AC. If 
the chip is selected (CS is Low), the 12 
address bits and the Write Enable bit are 



4-3 



General clocked into their respective internal registers. 

Description The block addressed by Ai-An is determined 

of the Z6132 by Ao; the other block is refreshed by the 7-bit 

(Continued) refresh counter. 

The Chip Select and address inputs must be 
held valid for only a short time after the rising 
edge of AC. This supports the multiplexing of 
address and data and allows enough setup time 
for the multiplexed data lines to settle with 
respect to the input control signal Data Strobe. 

A read cy cle i s initiated by th e rising edge 
of AC while CS is Low and WE is High. A Low 



on the DS input activates the data outputs after 
a specified delay. During a read operation, 
DS is only a static Output Enable signal. 

Write cycle i s in itiat ed b y the rising e dge o f 
AC while both CS and WE are Low. The WE 
input is ch ecked again on the falling edge of 
DS. If WE is still Low, the falling edge of DS 
strobes the data on the D0-D7 inputs into the 
addressed memory location. Data must be 
valid for only a short hold time after the falling 
edge of DS. 
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Figure i. Block Diagram 



Self -Refresh The Z6132 stores data in a single- transistor 

Operation dynamic cells that must be refreshed at least 

every 2 ms. Each of the two memory blocks 
contains 16,384 cells and reguires 128 refresh 
cycles to completely refresh the array. The 
Z6132 operates in one of two user-selectable 
self-refresh modes, each satisfying the refresh 
time requirements. On the basis of the 
available memory cycle time, the user can 
decide to use either the Long Cycle-Time 
Refresh mode or the Short Cycle-Time Refresh 
mode. The Long Cycle-Time Refresh mode is 
the simplest self-refresh mode and is enabled 
by permanently grounding the BUSY output 
pin of the Z6132. Every memory cycle in this 



mode consists of a memory operation followed 
by a refresh operation on both blocks, after 
which the refresh counter is incremented. 
Internally, the complete cycle consists of a 
four-phase sequence: 

1. Memory read, write, or write inhibit 

2. Precharge 

3. Refresh 

4. Precharge 

These internal operations are automatic and 
transpare nt to the user. When the chip is not 
selected (CS is High when AC goes High), the 
first two phases are omitted. There are two 
important requirements: the memory cycle 
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Self-Refresh times must always be longer than the TC 
Operation (mini mum m emory cycle time) value specified 

(Continued) when BUSY is Low, and there must be at least 
128 Address Clocks in any 2 ms period. 

The Long Cycle-Time Refresh mode is most 
practical for microprocessor applications 
where the read and write cycle times are in the 
range of 650-750 ns. The Short Cycle-Time 
Refresh mode is a more sophisticated self- 
refresh mode that is activated by pulling the 
BUSY output pin High through a pul lup 
resistor (typically 1 kfi) to Vqc- The BUSY out- 
puts of several Z6132 chips can be OR- wired 
together. In this mode, the Z6132 always per- 
forms a refresh operation on the memory block 
that is not being address ed f rom the outside. 
If the chip is selected (CS is Low when AC 
goes High), the refresh counter refreshes the 
block that is not addressed by Ao. The refresh 
counter is incremented after both an even and 
an odd address have occurred. This self- 
refresh scheme takes advantage of the sequen- 
tial nature of most mem ory addressing. If the 
chip is deselected (CS is High when AC goes 
High), both blocks are refreshed and the 
refresh counter is incremented after every 



cycle. Hence, the addressing of PROM or I/O 
can also be used to refresh the Z6132 by allow- 
ing it to receive Address Clocks without Chip 
Select. 

Under normal conditions, the deselected and 
odd/even self-refresh mechanisms step through 
128 refresh addresses in less than 2 ms. To 
guarantee proper refresh operation, even in 
the exceptional case of the memory being con- 
tinually selected and addressed by a long 
string of all even or all odd a ddresse s, a built- 
in cycle counter activates the BUSY output and 
requests a lengthened memory cycle to append 
a refresh operation. This internal cycle counter 
is reset whenever the refresh counter is incre- 
mented. The cycle counter then counts 
memory cycles and activates the BUSY output 
w hen it reaches a cou nt of 17 . 

BUSY is fed into the WAIT input of most 
microprocessors and is a reques t to the CPU 
for a longer memory cycle. The BUSY line is 
held Low by the Z6 132 until the refresh cycle 
has started. BUSY becomes active only when 
the Z6132 has been selected and addressed 
with all odd or all even addresses for 17 con- 
secutive Address Clocks. 



Interfacing The Z6132 was designed to interface with 

the Z6132 to Z-BUS™-compatible microporcessors such as 
the Z80A CPU the Z8 and Z8000. Although the Z80 does not 
directly produce Z- BUS- compatible memory 
signals, only three commonly available inte- 
grated circuits are required to interface the 
Z6132 with the Z80A CPU. The interface logic, 
circuit description, and timing diagrams for 
each important processor cycle are discussed 
later. Further information on the Z6132 and 
Z80A CPU can be obtained from the Z6132 
Product Specification (document number 
00-2028- A) and the Z80B CPU AC 
Characteristics (document number 00-2005- A). 

The Ml or opcode fetch cycle of the Z80A 
CPU represents the shortest memory cycle and 
must be given careful consideration when 
designing memory interface logic. Figure 2 
shows the Z80A CPU Ml cycle in detail along 
with worst- case delay timings for the important 
control signals. The maximum access time 
allowed for an opcode fetch (under ideal con- 
ditions) is 500 ns in clock cycles Ti and T2. 
Considering worst-case Z80A CPU data setup 
time (35 ns in T2) and worst-case opcode 



address stable time (110 ns in Ti), the max- 
imum access time available for a memory fetch 
is reduced to 355 ns. 

To keep the interface logic for the Z6132 to a 
minimum and still use commonly available 
parts, the Z6 132-5 (300 ns access time) is 
exemplified. Timing edges provided by the 
Z80A CPU clock are used to activate the Z6132 
Address Clock (signal AC shown in Figures 2, 
3, 4, and 5). Figure 7 shows the logic for the 
Z80A-to-Z6132 interface. The 74S00 NAND 
gate has a maximum delay of 5 ns, the 74LS04 
inverter has a maximum delay of 15 ns, and 
the 74S74 has a maximum clock to output 
delay of 9 ns. The clear-to-Q output Low delay 
is 8 ns for the 74S74. These numbers are 
displayed in th e tim ing diag rams for the Z6132 
control signals CS, AC, DS, and WE 
(Figures 2-6). 

The following description of a memory fetch 
cycle illustrates how each of the important 
Z6132 timing parameters is met. The Ml cycle 
begins with the activation of Z80A CPU control 
signal Ml in clock cycle Ti. Since the max- 
imum delay for Ml is 100 ns (Figure 2) and the 
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Interfacing maximum delay from the rising edge of Ti 
the Z6132 to until addresses are stable is 110 ns, the control 
the Z80A CPU path that gates Ml and CLK to clear the 74S74 
(Continued) flip-flop is used to force AC High. 

The delay of 33 ns shown in Figure 2 for AC 
from the falling edge of Ti was derived from 
the collective delays of the 74LS04 (15 ns), the 
74S00 (5 ns), the 74S74 clear (8 ns), and the 
final 74S00 gate (5 ns). Thus, under the worst 
conditions possible, a memory cycle begins 
with the rising edge of AC 158 ns after the 
rising edge of clock cycle Ti. 



As a reminder, the Ml machine cycle is a 
2-clock-cycle instruction fetch, which requires 
the data fetched to meet the specified setup 
time (35 ns) before the rising edge of clock 
cycle T3. With 35 ns required for worst-case 
data setup time, the remaining time in Ti and 
T2 for memory access is: 

500 ns - (158 ns + 35 ns) = 307 ns 

This allows the use of 300 ns access time RAMs 
even under worst- case conditions. 

The Z6 132-5 has a guaranteed access time of 
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Interfacing 300 ns and is recommended for use with the 
the Z6132 to Z80A CPU to simplify interface circuitry. This 
the Z80A CPU mode takes advantage of the self- refresh 
(Continued) feature of the Z6132 so that interfacing the 
Z80A CPU refresh control signals is not 
required. 

The 74S74 flip-flop is useful for two reasons. 
The Z80 A CPU refresh cycle, with its accom- 
panying MREQ, is effectively blocked by the 
74S74 during an Ml cycle. This is required 
because the refresh cycle during machine 



cycle Ml generates an MREQ signal that 
violates the AC timing requirements of the 
Z6132. The second purpose of the 74S74 is 
realized during an interrupt acknowledge 
cycle. The Z80A CPU uses th e simu ltaneous 
occurrence of Ml active with IORQ active to 
indicate that an interrupt acknowledge cycle is 
in progress. If the 74S74 flip-flop is removed, 
the Address Clock becomes active during 
every clock cycle time (425 ns) for the 
Z6 132-5. Figure 3 illustrates memory timing for 
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Interfacing the Z80A CPU me mory read or write cycle. In 
the Z6132 to this cycle, MREQ is issued by the Z80A CPU to 
the Z80A CPU initiate a memo ry opera tion. The Z80A CPU 
(Continued) control signals, MREQ and RD, closely track 
each other over the guaranteed temperature 
range. Were this not the case, DS could poten- 
tially become active before AC becomes true. 
The three 74LSQ4 inverters in the DS path help 
to insure that DS will become active only after 
AC has become true. Figure 3 shows WE in a 
memory read cycle. Only the occurrence of 
Ml (indicating an opcode fetch or an in terrupt 

acknowledge) or the occurrence of RD 

(indicating Ml or memory read) inhibit WE 
from becoming activ e. Duri ng a memory read, 
the close tracking of MREQ and RD insures 
that WE setup time to AC High ( - 10 ns) 
is met. 

Figure 4 shows a Z80A CPU I/O cycle along 
with the corresponding active Z6132 memory 
control signals. Since AC never makes a 
positive transition during this I/O cycle, the 



othe r memory control signals (such as CS and 
DS) do not affect operation of the Z6132. 
Figure 5 shows a Z80A CPU interrupt 
acknowledge cycle. A lthou gh AC makes a 
positive transition and CS could be true 
(depending on the Z80A CPU's current PC), 
the memory control signal DS never becomes 
active during an interrupt acknowledge cycle. 
This cycle appears to be an aborted read cycle 
to the Z6132 and has no harmful effect. 

Thus, with only three commonly available 
14-pin packages, a simple interface between 
the Z80A CPU and the Z6132 can be con- 
structed. The Z80A was chosen for this appli- 
cation example because it allows 4 MHz opera- 
tion while using relatively inexpensive (300 ns) 
memory. Operation of the Z80B CPU (6 MHz) 
provides for a maximum memory access time 
of 210 ns in the opcode fetch cycle (not 
including memory interface logic) under worst- 
case conditions. Figure 6 shows the timing for 
the Z80B opcode fetch cycle with its associated 
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Interfacing maximum delays. In this configuration, one 
the Z6132 to wait state can be inserted to increase the 
the Z80A CPU available access time to 375 ns. In systems that 
(Continued) require higher performance, the Z80B CPU 
(even with one wait state included in opcode 



fetch cycles) can increase processor execution 
efficiency. The Z80 CPU (2.5 MHz) is also 
easily interfaced with the Z6132 family. Here, 
as with the Z80A CPU, no additional wait 
states need to be added. 
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Interfacing 
the Z6132 to 
the Z80A CPU 

(Continued) 
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Figure 7. Z80A/Z6132 Interface Logic 



Interfacing Two Z6132s are interfaced to a Z8002 (non- 

the Z6132 to segmented Z8000) in this example to provide 
the Z8002 CPU 4K words (16 bits wide) of buffer storage. 
Three external TTL packages provide all 
address chip select and byte/word decoding to 
the Z6132s. The timing diagrams (Figures 
8-10), the interface logic (Figure 11), and the 
circuit description are discussed later. Infor- 
mation on the Z8002 CPU can be obtained 
from the Z8000 CPU Product Specification 
(document number 00-2045- A), the 
Z8001/Z8002 CPU AC Characteristics (docu- 
ment number 00-2004- A) and from the Z8000 



CPU Technical Manual (document number 
00-20 10-C). A Z8002 running at 4 MHz was 
chosen to provide high throughput while still 
providing a generous memory access time of 
360 ns for the Z6132s (Figures 8-10). The 
Z6 132-6 chosen for this example has a max- 
imum access time of 350 ns. All Z8002 memory 
transactions are three clock cycles long and 
conform to the Zilog Z-BUS timing specifica- 
tions. More information on the Zilog Z-BUS can 
be found in the Z-BUS Summary (document 
number 00-2031 -A). 
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Interfacing The Z8002 uses a multiplexed address/data 

the Z6132 to bus to provide for memory addressing and 
the Z8002 CPU data transfer. The rising edge of Address 
(Continued) Strobe (AS) guarantees that addresses from the 
Z8002 are stable. This signal (AS) is fed 
directly to the Z6132s as the Address Clock 
(AC) input clocks in memory addresses and 
initiates a mem ory c ycle. The Z6132 samples 
its Chip Select (CS) pin with the rising edge of 
AC to determine whe ther the bus transaction is 
intended for it. If CS is found Low on the ris- 
ing edge of AC, the Z6132 begins a read or 

write operatio n, de pending on the state of its 

Write Enable (WE) pin. The Z6132 samples WE 
a gain on the falling edge of Data Strobe (DS). 
If WE is still Low, the write cycle is continued. 
If WE has returned to the High state, the 
memory write cycle to the Z6132 is aborted. 
This feature of the Z6132 allows memory write 
cycles to be suppressed if determined 
undesirable, without paying an access-time 
penalty. The R/W sign al is fed directly from 
the Z8002 to the Z6132 WE pin. The signal DS 
from the Z8002 indicates when valid data is 
available on the multiplexed adress/data bus. 
This signal indicates if valid CPU data is 
available to the Z6132 during a write cycle and 
enables the Z6132 output buffers during a CPU 
read cycle. The DS signal from the CPU is fed 
directly to the DS input of the Z6132. The only 
interface circuitry between the Z8002 and the 
Z6132 is the decoding of reguired byte/ word, 
read/write, and high-byte/low-byte Z8002 
memory control functions (Figure 11). A 
74LS157 dual multiplexer is used to provide 



enable signals for the even and odd banks of 
Z6132s. The truth table for this multiplexer 
follows. Both even and odd banks are enabled 
except during byte operations. During byte 
write operations, only one bank of Z6132s is 
enabled. This bank is determined by ADq. 



INPUTS 



OUTPUTS 



R/W AD B/W 

(Enable) (B/A Select) (1A, 2B) 

0X0 
1 

1 1 

1 X X 



EVEN ODD 



1 

1 




X = don't care 

When the Z8002 performs a read operation, 
16 bits of memory data are returned to the 
CPU. For byte read transactions, the appro- 
priate (odd or even) byte is selected internally 
to the Z8002. The enable input for the 74LS157 
is active Low. When the R/W output of the 
Z8002 is High (indicating a read operation), 
the 74LS157 is disabled, forcing the even and 
odd outputs Low. During a write operation, the 
74LS157 is enabled and the even and odd out- 
puts are determined by the states of the B/W 
and ADo CPU outputs. During a word-write 
operation, both even and odd outputs are 
enabled. During a byte- write operation, the 
enabled even or odd bank is determined by 
the least significant address bit (ADo). A byte- 
write to an even address (ADo is 0) cor- 
responds to an even enable. When this byte is 
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Figure 8. Z8000 Memory Transaction (6.0 MHz) 
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Interfacing read back from the Z6132, the Z8002 expects it 
the Z6132 to to appear on the upper eight data bits 
the Z8002 CPU (AD 8 -ADi 5 ). The lower eight data bits are con- 
( Continued) nected to the odd bank, and the upper eight 
data bits are connected to the even bank. The 
least significant address bit (ADo) is not con- 
nected to the Z6132 (although it still functions 



as a data bit). It is used instead in the selection 
of even or odd Z6132 banks. A 74LS138 is used 
to further decode even and odd addresses into 
individual even and odd Chip Selects for the 
Z6132s. Memory transactions (excluding 
refresh operations) are reflected by status bit 
03 (High) of the Z8002 CPU. This bit is fed to 
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Interfacing the 74LS138s as a Chip Enable to inhibit 
the Z6132 to memory Chip Selects during I/O operations 
the Z8002 CPU that might correspond to the same address as 
(Continued) one of the Z6132s. 

The only timing parameter that requires 
explanation in this interface is the Chip Select 
timing (Figure 10) pertaining to the Z6132 
Address Clock. All other timing parameters 
shown are generated by the Z8002 (no buffer- 
ing is included) and meet the required setup, 
delay, and hold times for the Z6132. The Z8000 
guarantees at least 55 ns delay from memory 
address es s table to the rising edge of Address 
Strobe (AS from the Z8002, AC to the Z6132). 
The worst-case timing condition for Chip 
Select to the Z6132 occurs during byte- write 
memory transactions. A maximum delay of 
21_ns is introduced in the 74LS157 from the 
R/W input to the odd or even outputs. The 
74LS138 decoders add a maximum worst-case 



delay of 32 ns from the decoder enable to 
the decoder outputs. The total byte- write 
Chip Select delay from address stable 
(21 ns + 32 ns) comes to 53 ns under worst- 
case timing considerations. Since t he C hip 
Select setup time to AC is ns, the CS-to-AC 
requirements for the Z6132 are satisfied. 

Thus, with three low-power Schottky TTL 
packages, the Z8002 can access up to 64K 
bytes of primary memory in 8K-byte incre- 
ments. The lowest 4K bytes are usually 
reserved for bootstrap ROM, but circuitry 
could be included to disable the ROM after 
bootstrap to provide a full 64K bytes of Z6132 
RAM storage. The memory transaction timing 
diagram for 6-MHz Z8002 operation is included 
in Figure 8 for high-performance Z8002 
designs. The Z6132-3 has a guaranteed access 
time of 200 ns and is suggested for use with 
the 6-MHz Z8001 or Z8002. 




Figure 11. Z8000/Z6132 Interface Logic 



-'/ 



4-13 



Interfacing In the following example, a Z6 132-5 (300 ns) 

the Z6132 is interfaced to a Z8 operating at 7.3728 MHz. 

to the Z8 Timing for interfacing the Z8 to a Z6 132-4 

(250 ns) is discussed for 8-MHz Z8 operation. 
In addition, the example describes 2716 and 
2732 EPROM interchangeability with the 
Z6132. Timing diagrams and circuit drawings 
have been included for Z8 memory interface 
timing and are discussed in this section. 

The Z8 is an 8-bit, general-purpose micro- 
computer chip that can be configured under 
software control. The Z8 features regular archi- 
tecture with 144 on-chip registers, 2K bytes of 
on-chip ROM, and 32 I/O lines configured for 
conventional I/O or for external memory. 
Detailed information on the Z8 can be found in 
the Z8 Microcomputer Technical Manual 
(document number 03-3047-02) and the 
Z8601/2/3 MCU Microcomputer Product 
Specification (document number 00-2037- A). 
The Z8 uses Port 1 (eight bits wide) as a 



multiplexed address/data bus and Port as the 
upper byte of a 16-bit address bus. Before 
external memory references to the Z6132 can 
be made by any instruction, the user must con- 
figure Ports and 1 appropriately. Instruction 
pipelining mandates that after setting the 
modes of Ports and 1 for external memory 
operation, the next two bytes are fetched from 
internal program memory. Two single-byte 
instructions, such as NOPs, can be used to 
accomplish this. On- board ROM in the Z8 is 
available from 0000-07FF (Hex). This applica- 
tion locates the external Z6132 in the Z8 
address space from 1000-1FFF (Hex). 

All Z8 timing references are made wit h 
respect to the output signals AS and DS. The 
control signal AS indicates when the Z8 
address bus is valid, while the control signal 
DS controls the flow of data. The Z8 status 
signal R/W (Read/Write) indicates the direc- 
tion of data flow. The Z8 indicates when a 
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Interfacing hardware reset operation is in progress by 
the Z6132 activating DS while outputting AS at the inter- 

to the Z8 nal clock rate. Since the internal clock has a 

(Continued) cycle time period of 250 ns, it is necessary to 
inhibit AS during hardware reset operations so 
that the minimum memory cycle time for the 
Z6132 is not violated. This is easily accom- 
plished by using the reset line to the Z8 as an 
inhibit line to the AC input of the Z6132 
(Figure 12). The 74LS32 OR gate delays the 
Address Clock to the Z6132 a maximum 
of 22 ns. 



The basic memory cycle of the Z8 is six 
clock cycles (810 ns at 7.3728 MHz). An 
extended cycle mode is available under soft- 
ware control that lengthens memory access by 
one clock cycle. At 8 MHz, this cycle is reduc- 
ed to 750 ns. In either case, the Z6132 timing 

parameters TC (read or write cycle time), 

TwACh (AC width High), and TdDS(AC) (DS 
Low to AC High) all allow the Z6132 to be 
used in the Long Cycle-Ti me Ref resh mode. 
For this reason, the Z6132 BUSY line is per- 
manently grounded. 



EPROM The Z6132 is packaged in an industry- 

Compatibility standard, 28-pin DIP and is pin compatible 

with the proposed JEDEC standard. This allows 
the substitution of other 28-pin DIPs that con- 
form to the proposed JEDEC standard (namely 
the 2732 and 2716 EPROMs). The 2732 EPROM 
requires only that +5 V (Vcc) be substituted 
for AC (pin 26 on the Z6132). This substitution 
can be accomplished easily with a jumper 
(Figure 12). Interfacing a 2716 requires one 
additional jumper change. The 2716 EPROM is 
only 2K bytes, and hence requires only 11 
address bits for full addressing capability. A 
second jumper pad for 2716 selection can be 



included to tie pin 23 to a pullup resistor as 
required for reading a 2716. 

Since the Z8 multiplexes addresses and data 
on Port 1 , it is necessary to latch the low-order 
address byte with the Z8 control signal AS. 
This latch is unnecessary for systems without 
2716/2732 EPROM capability, since the 
address to the Z6132 may change after the 
specified address hold time (60 ns for the 
Z6 132-5). The 2716 and 2732 EPROMs are 
24-pin packages, and the Z6132 is a 28-pin 
package. This requires the EPROMs to be 
physically justified so that pin 1 of the 
2716/2732 is aligned with pin 3 of the Z6132. 



Theory of Figure 12 shows the circuit diagram for a 

Operation small Z8 system. In this configuration, a series 

resonant crystal (7.3728 MHz) provides all 
system timing. Port 1 is configured for 
multiplexed address and data, and Port is 
configured to provide the upper address byte 
to complete the 12-bit address bus required by 
the Z6132 and to provide four bits of address 
decoding. The upper bits of Port (PO4 to PO7) 
are decoded by a 74S138 to provide eight 
blocks, each 4K bytes long. The first block is 
discarded because it overlaps with internal Z8 
ROM . The second segment is used to generate 
CS for the Z6132, and the last six segments are 
free for other system chip select decoding, 
such as additional memory or external I/O 
ports. A 74LS373 is used to latch addresses 
from the multiplexed address/ data bus of Port 
1 . This latch is enabled when AS is active 



(Low) and retains the addresses after AS has 
returned High. The Z6132 does not require 
addresses to be stable throughout the entire 
memory cycle, so this latch is used only with 
systems that provide the option of using the 
2716 and 2732 EPROMs. Addresses are latched 
internally to the Z6132 on the rising edge of 
AC. Jumpers Jl and J2 are connected as shown 
for Z6132 operation. To substitute a 2732 for 
the Z6132, the existing jumper (Jl) must be cut 
from the Z6132 pin 26 to the Z8 pin 9, and 
Z6132 pin 26 is connected to Vqc- To 
substitute a 2716, one additional jumper 
change must be made. Jumper J2 is shown 
connected for Z6132 and 2732 operation. To 
substitute a 2716, the existing jumper is cut 
from the Z6132 pin 23 to the Z8 pin 16, and the 
jumper at J2 from the Z8 pin 23 is connected to 
the 4.7K pullup resistor. 
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Timing The important control signals for memory 

interface to the Z8 have been reproduced in 
Figures 13-16. In this design example, a 
crystal frequency of 7.3728 MHz was selected 
for overall system timing. The Z8 product 
specifications provide timing specifications at 
8 MHz. To calculate the timing parameters for 
frequencies other than 8 MHz, the timing 
parameters are derated by a factor based on 
the difference in clock period. For instance, 
the timing parameter TdA(AS) is given as 
30 ns (mm) for a clock input of 8 MHz. To 



calculate the timing value for a clock input of 
7.3728 MHz, the difference in clock periods 
(135.6 ns - 125.0 ns = 10.6 ns) must be 
added to the value given in the Z8 product 
specifications. Hence, the delay time for 
TdA(AS) with a 7.3728 MHz clock is_40.6 ns 
(30 ns + 10.6 ns = 40.6 ns). The AS signal 
has a guaranteed minimum width of 70.6 ns at 
7.3728 MHz. The Z8 guarantees that addresses 
will be stable 40.6 ns before the rising edge of 

AS. With the additional maximum delay of 

22 ns for the 74LS32, the resultant signal (AS) 
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Figure 13. Z6132 Memory Timing (8.0 MHz) 
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Figure 14. External Memory Timing (8.0 MHz) 
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Timing is fed directly to the Address Clock input of 

(Continued) the Z6132. The low-byte address encounters a 
maximum delay of 30 ns through the 74LS373 
latch. The status signal R/W and the data bus 
control signal DS are_fed directly to the Z6132. 
The status signal R/W is available to the Z6132 
40.6 ns before the r ising edge of AC. The 
maximum delay for CS through the 74S138 is 
12 n s. This still leaves 27.4 ns setup time for 
CS to AC, although ns is the minimum 
reguirement. The maximum access time for an 
external memory operation at 7.3728 MHz is 
calculated to be 322.4 ns (Figure 14). This 



access time begins with the rising edge of AC 
and includes the data setup time to the Z8 
CPU. This access time allows the use of low- 
speed Z6 132-5 (300 ns) RAMs. For systems that 
reguire higher performance, the Z6 132-4 can 
be used with an 8-MHz Z8 CPU. Timing for the 
Z8 at 8 MHz has been included in Figure 13. 
The maximum access time allowed for external 
RAM by the Z8 when operating at 8 MHz is 
280 ns. The Z6 132-4 has an access time of 
250 ns, making it directly compatible with 
an 8-MHz Z8. 
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Figure 15. Z6132 Memory Timing (7.3728 MHz) 
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Figure 16. External Memory Timing (7.3728 MHz) 
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A Minimum Figure 17 illustrates the simplicity with 

Z8 System which a Z8601/Z6132 system is reduced to a 

minimum chip count. The expansion bus of the 
Z8601 and the interface to the Z6132 are Z-BUS 
compatible. As a result, the two parts connect 



directly without additional logic. As mentioned 
in the previous section, the access time of 
the Z6 132-4 meets the requirements of an 
8-MHz 78. 
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Figure 17. Z8601/Z6132 Minimum System 



Summary The Z6132 is a versatile, intelligent byte- 

wide RAM, which provides an attractive solu- 
tion for primary buffer storage. Because the 
Z6132 provides two modes of self- refresh, the 
user can select between executing a refresh 
after each memory access or taking advantage 
of the inherent seguential access of most 



memory systems. The Z6132 is an industry- 
standard, 28-pin DIP that conforms to the 
JEDEC recommended pinout and is inter- 
changeable with 2716/2732-type EPROMs. The 
Z6132 is Z-BUS compatible and interfaces 
easily with the 28, Z80, and Z8000 Families of 
microprocessors . 
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Features ■ Multiplexed address/data bus shared by 

memory and I/O transfers. 

■ 16 or more memory address bits; 16-bit I/O 
addresses; 8 or 16 data bits. 

■ Supports polling and vectored or non- 
vectored interrupts. 

■ Daisy- chain interrupt structure services 
interrupts without a separate priority 
controller. 



Direct addressing of registers within a 
peripheral facilitates I/O programming. 

Bus signals allow asynchronous CPU and 
peripheral clocks. 

Daisy-chain bus-reguest structure supports 
distributed control of the bus. 

Shared resources can be managed by a 
general-purpose, distributed resource- 
reguest mechanism. 



General The Z-BUS is a high-speed parallel shared 

Description bus that links components of the Z8000 Family. 
It provides family members with a common 
communication interface that supports the 
following kinds of interactions: 

■ Data Transfer. Data can be moved between 
bus controllers (such as a CPU) and mem- 
ories or peripherals. 

■ Interrupts. Interrupts can be generated by 
peripherals and serviced by CPUs over 
the bus. 

■ Resource Control. Distributed management 
of shared resources (including the bus itself) 
is supported by a daisy-chain priority 
mechanism. 

The heart of the Z-BUS is a set of multi- 
plexed address/data lines and the signals that 
control these lines. Multiplexing data and 
addresses onto the same lines makes more effi- 
cient use of pins and facilitates expansion of 
the number of data and address bits. Multi- 
plexing also allows straightforward addressing 
of a peripheral's internal registers, which 
greatly simplifies I/O programming. 

A daisy-chained priority mechanism resolves 
interrupt and resource reguests, thus allowing 
distributed control of the bus and eliminating 
the need for separate priority controllers. The 
resource- control daisy chain allows wide 
physical separation of components. 

The Z-BUS is asynchronous in the sense that 
peripherals do not need to be synchronized 
with the CPU clock. All timing information is 
provided by Z-BUS signals. 
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Figure 1. Z-BUS Signals 
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Z-BUS A Z-BUS component is one that uses Z-BUS 

Components signals and protocols, and meets the specified 
ac and dc characteristics. Most components in 
the Z8000 Family are Z-BUS components. The 
four categories of Z-BUS components are as 
follows: 

CPUs. A Z-BUS system contains one CPU, and 
this CPU has default control of the bus and 
typically initiates most bus transactions. 
Besides generating bus transactions, it handles 
interrupt and bus- control requests. The Z8001 
Segmented CPU and Z8002 Non-Segmented 
CPU are Z-BUS CPUs. 

Peripherals. A Z-BUS peripheral is a com- 
ponent capable of responding to I/O trans- 
actions and generating interrupt requests. The 
Z8036 Counter Input/Output Circuit (Z-CIO), 



Z8038 FIFO Input/Output Interface Unit 
(Z-FIO), the Z8030 Serial Communication 
Controller (Z-SCC), the Z8090 Universal 
Peripheral Controller (Z-UPC), and the 
Z8052 CRT Controller (Z-CRT) are all 
Z-BUS peripherals. 

Requesters. A Z-BUS requester is any com- 
ponent capable of requesting control of the 
bus and initiating transactions on the bus. A 
Z-BUS requester is usually also a peripheral. 
The Z8016 DMA Transfer Controller (Z-DTC) is 
a Z-BUS requester and a peripheral. 

Memories. A Z-BUS memory is one that inter- 
faces directly to the Z-BUS and is capable of 
fetching and storing data in response to Z-BUS 
memory transactions. The Z6132 Quasi-Static 
RAM is a Z-BUS memory. 



Other The Z8 Microcomputer — in its micro- 

Components processor configuration — conforms to Z-BUS 
timing (which allows it to use Z-BUS 
peripherals and memories), but is missing a 
wait input and certain status outputs. 

The Z8010 Memory Management Unit 
(Z-MMU) is a Z8000 CPU support component 
that interfaces with part of the Z-BUS on the 
CPU side and provides demultiplexed 



addresses on the memory side. 

The Z8060 First-In-First-Out Buffer (Z-FIFO) 
is not a Z-BUS component; rather, it is used to 
expand the buffer depth of the Z-FIO or to 
interface the I/O ports of the Z-UPC, Z-CIO, 
or Z-FIO to user equipment. 

Z-80 Family components, while not 
Z-BUS compatible, are easily interfaced to 
Z-BUS CPUs. 



Operation Two kinds of operations can occur on the 

Z-BUS: transactions and requests. At any given 
time, one device (either the CPU or a bus 
requester) has control of the Z-BUS and is 
known as the bus master. A transaction is 
initiated by a bus master and is responded to 
by some other device on the bus. Four kinds of 
transactions occur in Z-BUS systems: 

■ Memory. Transfers 8 or 16 bits of data to or 
from a memory location. 

■ I/O. Transfers 8 or 16 bits of data to or from 
a peripheral. 

■ Interrupt Acknowledge. Acknowledges 
an interrupt and transfers an identi- 
fication/status vector from the interrupting 
peripheral. 

■ Null. Does not transfer data. Typically used 
for refreshing memory. 

Only one transaction can proceed on the bus 



at a time, and it must be initiated by the bus 
master. A request, however, may be ini- 
tiated by a component that does not have con- 
trol of the bus. There are three kinds of 
requests: 

■ Interrupt. Requests the attention of the 
Z-BUS CPU. 

■ Bus. Requests control of the Z-BUS to ini- 
tiate transactions. 

■ Resource. Requests control of a particular 
resource. 

When a request is made, it is answered 
according to its type: for interrupt requests an 
interrupt- acknowledge transaction is initiated; 
for bus and resource requests an acknowledge 
signal is sent. In all cases a daisy-chain pri- 
ority mechanism provides arbitration between 
simultaneous requests. 
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Signal The Z-BUS consists of a set of common signal 

Lines lines that interconnect bus components (Figure 

1). The signals on these lines can be grouped 
into four catagories, depending on how they 
are used in transactions and requests. 

Primary Signals. These signals provide 
timing, control, and data transfer for Z-BUS 
transactions. 

ADq-ADi 5 . Address/Data (active High). These 
multiplexed data and address lines carry I/O 
addresses, memory addresses, and data during 
Z-BUS transactions. A Z-BUS may have 8 or 16 
bits of data depending on the type of CPU. In 
the case of an 8-bit Z-BUS, data is transferred 
on AD0-AD7. 

Extended Address, (active High). These 
lines extend ADq-ADjs to support memory 
addresses greater than 16 bits. The number of 
lines and the type of address information 
carried is dependent on the CPU. 

Status, (active High). These lines designate 
the kind of transaction occurring on the bus 
and certain additional information about the 
transaction (such as program or data memory 
access or System versus Normal Mode). 

AS. Address Strobe (active Low). The rising 
edge of AS indicates the beginning of ^trans- 
action and that the Address, Status, R/W, and 
B/W signals are valid. 

DS. Data Strobe (active Low). DS provides 
timing for data movement to or from the bus 
master. 

R/W. Read/Write (Low = write). This signal 
determines the direction of data transfer for 
memory or I/O transactions. 

B/W. Byte/Word (Low = word). This signal 
indicates whether a byte or word of data is to 



be transmitted on a 16-bit bus. This signal is 
not present on an 8-bit bus. 



WAIT, (active Low). A Low on this line indi- 
cates that the responding device needs more 
time to complete a transaction. 



RESET, (active Low). A Low on this line resets 
the CPU and bu s users. Peripherals may be 
reset by RESET or by holding AS and DS Low 
simultaneously. 

CS. Chip Select (active Low). Each peripheral 
or memory component has a CS line that is 
decoded from the address and status lines. A 
Low on this line indicates that the peripheral 
or memory component is being addressed by a 
transaction. The Chip Select information is 
latched on the rising edge of AS. 

CLOCK. This signal provides basic timing for 
bus transactions. Bus masters must provide all 
signals synchronouly to the clock. Peripherals 
and memories do not need to be synchronized 
to the clock. 

Bus Request Signals. These signals make 
bus requests and establish which component 
should obtain control of the bus. 



BUSREQ. Bus Request (active Low). This line 
is driven by all bus requesters. A Low indi- 
cates that a bus requester has or is trying to 
obtain control of the bus. 



BUSACK. Bus Acknowledge (active Low). A 

Low on this line indicates that the Z-BUS CPU 
has relinquished control of the bus in response 
to a bus request. 



BAI, BAO. Bus Acknowledge In, Bus 
Acknowledge Out (active Low). These signals 
form the bus-request daisy chain. 
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Output 
3-state 

Output 
3-state 

□ 

~ Input" 

Input 

Input 

Output 

□ 
□ — 



Input 

D 

□ 

D 

Output 

Open Drain 

Input 

Input 

Output 



Requester 

Bidirectional 2 
3-state 

Output 
3-state 

Output 
3-state 

Output 
3-state 



Output 

Input 

Output 
3-state 

Output 
3-state 

□ 

Input 13 

Input 

Bidirectional 
Open Drain 

□ 

Input 

Output 



□ 

□ 
□ 
D 



Peripheral 

Bidirectional 1 
3-state 

□ 



Inputs 



Input 
■ Input 3 - 



Output 8 
Open Drain 

Input 



Input 

Input 

■ Input 5- 

Input 8 

□ 



□ 
□ 

□ 

Output 
Open Drain 

Input 11 

Input 

Output 



Memory 

Bidirectional 2 
3-state 

Input 

□ 

Input 

Input 

Output 8 
Open Dram 

Input 



Input 

Input 

— □ — 
Input 8 

□ 

□ 
□ 

— □ — 

□ 
□ 
□ 
□ 



1. Only AD0-AD7, unless peripheral is 16- Bit. 

2. For an 8-bit bus, only ADQ-AD7 are bidirectional. 

3. Only for a 16- bit peripheral. 

4. Derived signal, one for each peripheral or memory; decoded 
from status and address lines. 

5. Optional — peripherals are typically reset by AS and DS being 
Low simultaneously; however, they can have a reset input. 

6. Derived signal; decoded from status lines. 

7. Daisy-chain lines. 

8. Optional signal(s). 

9. For 16-bit data bus only. 



10. Optional — usually only input on peripherals that are also 
requesters. 

1 1 . May be omitted if peripheral inputs status lines. 

12. Optional signal; any component may attach to the resource 
request lines. 

13. Optional signal; a bus r equestor may also be reset by AS and 
DS going Low and BAI being High simultaneously. 

14. This signal is optional if there are no requesters on the bus. 
CPU timing can be provided by alternate means such as 
crystal oscillator inputs. 

□ No Connection 



Table 1. Z-BUS Component Connections to 
Signal Lines. This table shows how the various 
Z-BUS components attach to each signal line. 
When a device is both a bus requester and a 



peripheral, the attributes in both columns of 
the table should be combined (e.g., input 
combined with output and 3-state becomes ( 
bidirectional and 3-state.) 
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Signal 
Lines 

(Continued) 



Interrupt Signals. These signals are used for 
interrupt requests and for determining which 
interrupting component is to respond to an 
acknowledge. To support more than one type 
of interrupt, the lines carrying these signals 
can be replicated. (The Z8000 CPU supports 
three types of interrupts: non-maskable, vec- 
tored, and non-vectored.) 

INT. Interrupt (active Low). This signal can 
be driven by any peripheral capa ble of gener- 
ating an interrupt. A Low on INT indicates that 
an interrupt request is being made. 



Resource Request Signals. These signals are 
used for resource requests. To manage more 
than one resource, the lines carrying these 
signals can be replicated. (The Z8000 supports 
one set of resource request lines.) 



INTACK. Interrupt Acknowledge (active 
Low). This signal is decoded from the status 
lines. A Low indicates an interrupt acknowl- 
edge transaction is in progress. This signal 
is latch ed b y the peripheral on the rising 
edge of AS. 

IEI, IEO. Interrupt Enable In, Interrupt Enable 
Out (active High). These signals form the 
interrupt daisy chain. 



MMRQ. Multi-Micro Request (active 
Low). This line is driven by any device that 
can use the shared resource. A Low indicates 
that a request for the resource has been made 
or granted. 

MMST. Multi-Micro Status (active Low). This 
pin allo ws a device to observe the va lue of th e 
MMRQ line. An input pin other tha n MMRQ 
facilitates the use of line drivers for MMRQ. 



MMAI, MMAO. Multi-Micro Acknowledge In, 
Multi-Micro Acknowledge Out (active 
Low). These lines form the resource- request 
daisy chain. 



Transactions All transactions start with Address Strobe 

being driven Low and then raised High by the 
bus master (Figure 2). The Status lines are 
valid on the rising edge of Address Strobe and 
indicate the type of transactions being initi- 
ated. If the transaction requires an address, 
it must also be valid on the rising edge 
of Address Strobe. 

For all transactions except null transactions 
(which do nothing beyond this point), data is 
then transferred to or from the bus master. The 
bus master uses Data Strobe _to time the move- 
ment of data. For a read (R/W = High), the 



bus master makes AD0-AD15 inactive before 
driving Data Strobe Low so that the 
addressed memory or peripheral can put its 
data on the bus. The bus master samples this 
data just before raising Data Strobe High. For 
a write (R/W = Low), the bus master puts the 
data to be written on AD0-AD15 before forcing 
Data Strobe Low. 

For an 8-bit Z-BUS, data is transferred on 
AD0-AD7. Address b»ts may remain on 
AD8-AD15 while DS is Low. 



/ \ / 



ST0-ST3 

R/W, B/W 



w n 



x 



a r 



x 



x 



x 
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~f BUS MASTERA 

SAMPLES 

INPUT DATA 



> / 






< 



XZA 






f 



DATA FROM BUS MASTER 



X 



\ 



>-c 



X 



Figure 2. Typical Transaction Timing 
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Memory For a memory transaction, the Status lines 

Transactions distinguish among various address spaces, 

such as program and data or system and nor- 
mal, as well as indicating the type of trans- 
action. The memory address is put on 
AD0-AD15 and on the extended address lines. 
For a Z-BUS with 16-bit data, the memory is 
organized as two banks of eight bits each 
(Figure 3). One bank contains all the upper 



bytes of all the addressable 16-bit words. The 
other bank contains all thejower bytes. When 
a smgle byte is written (R/W = Low, 
B/W = High), only the bank indicated by 
address bit Ao is enabled for writing. 

For a Z-BUS with 8-bit data, the memory is 
organized as one bank which contains all 
bytes. This bank always inputs and outputs its 
data on AD0-AD7. 



16-BIT Z-BUS DATA PATH 




EXTENDED 
ADDRESS 



■3 

3 



sos mwm receivers 



JL 



appm 

BYTE 
BAHK 



B/W-O^ 

Ao t ^ °- 



i^O-' 



UPPER 
BANK 
ENABLE 



3> 



H 



LOWER 
BYTE 
BANK 



LOWER 

BANK 

ENABLE 



Figure 3. Byte/ Word Memory Organization 



I/O I/O transactions are similar to memory 

Transactions transactions with two important differences. 
The first is that I/O transactions take an extra 
clock cycle to allow for slow peripheral oper- 
ation. _The second is that byte data (indicated 
by B/W High on a 16-bit bus) is always trans- 



mitted on ADq-AD7, regardless of the I/O 
address. (AD8-AD15 contain arbitrary data in 
this case.) For an I/O transaction, the address 
indicates a peripheral and a particular register 
or function within that peripheral. 



Null The two kinds of null transactions are dis- 

Transactions tinguished by the Status lines: internal oper- 
ation and memory refresh. Both transactions 
look like a memory read transaction except 
that Data Strobe remains High and no data is 
transferred. 

For an internal operation transaction, the 
Address lines contain arbitrary data when 
Address Strobe goes High. This transaction is 
initiated to maintain a minimum transaction 
rate when a bus master is doing a long internal 



operation (to support memories which generate 
refresh cycles from Address Strobe). 

For a memory refresh transaction, the 
Address lines contain a refresh address when 
Address Strobe goes High. This transaction is 
used to refresh a row of a dynamic memory. 

Any memory or I/O transaction can be sup- 
pressed (effectively turning it into a null trans- 
action) by keeping Data Strobe High through- 
out the transaction. 



Interrupts A complete interrupt cycle consists of an 

interrupt request followed by an interrupt- 
acknowled ge tr ansaction. The request, which 
consists of INT pulled Low by a peripheral, 
notifies the CPU that an interrupt is pending. 
The mterrupt-acknowledge transaction, which 
is initiated by the CPU as a result of the 
request, performs two functions: it selects the 
peripheral whose interrupt is to be acknowl- 
edged, and it obtains a vector that identifies 
the selected device and cause of interrupt. 

A peripheral can have one or more sources 
of interrupt. Each interrupt source has three 



bits that control how it generates interrupts. 
These bits are an Interrupt Pending bit (IP), 
and Interrupt Enable bit (IE), and an Interrupt 
Under Service bit (IUS). 

A peripheral may also have one or more 
vectors for identifying the source of an inter- 
rupt during an interrupt- acknowledge trans- 
action. Each interrupt source is associated with 
one interrupt vector and each interrupt vector 
can have one or more interrupt sources associ- 
ated with it. Each vector has a Vector Includes 
Status bit (VIS) controlling its use. 

Finally, each peripheral has three bits for 



386 
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Interrupts controlling interrupt behavior for the whole 

(Continued) device. These are a Master Interrupt Enable 
bit (MIE), a Disable Lower Chain bit (DLC), 
and a No Vector bit (NV). 

Peripherals are connected together via an 
interrupt daisy chain formed with their IEI and 
IEO pins (Figure 4). The interrupt sources 
within a device are similarly connected into 
this chain with the overall effect being a daisy 
chain connecting the interrupt sources. The 
daisy chain has two functions: during an 
interrupt-acknowledge transaction, it deter- 
mines which interrupt source is being 
acknowledged; at all other times it determines 
which interrupt sources can initiate an inter- 
rupt reguest. 

Figure 5 is a state diagram for interrupt 
processing for an interrupt source (assuming 
its IE bit is 1). An interrupt source with an 
interrupt pending ( IP = 1) makes an interrupt 
request (by pulling INT Low) if, and only if, it 
is enabled (IE = 1, MIE= 1), it does not have 
an interrupt under service (IUS = 0), no 
higher priority interrupt is being serviced 
(IEI = High), and no interrupt-acknowledge 
transacti on is in progress (as indicated by 
INTACK at the last rising edge of AS). IEO is 
not pulled down by the interrupt source at this 
time; IEO continues to follow IEI until an 
interrupt-acknowl edge transaction occurs. 

Some time after INT has been pulled Low, 
the CPU initiates an interrupt-acknowledge 



transaction (indicated by INTACK Low). 
Between the rising edge of AS and the falling 
edge of DS, the IEI/IEO daisy chain settles. 
Any interrupt source with an interrupt pending 
(IP = 1, IE = 1, MIE = 1) or under service 
(IUS = 1) holds its IEO line Low; all other 
interrupt sources make IEO follow IEI. When 
DS falls, only the highest priority interrupt 
source with a pending interrupt (IP = 1) has 
its IEI input High, its IE bit set to 1, and its 
IUS bit set to 0. This is the interrupt source 
being acknowledged, and at this point it sets 
its IUS bit to 1, and, if the peripheral's NV bit 
is 0, identifies itself by placing the vector on 
AD0-AD7. If the NV bit is 1, then the periph- 
eral's ADo - AD7 pins remain floating, thus 
allowing external circuitry to supply the vec- 
tor. (All interrupts, including the Z8000's non- 
vectored interrupt, need a vector for identify- 
ing the source of an interrupt.) If the vector's 
VIS bit is 1 , the vector will also contain status 
information further identifying the source of 
the interrupt. If the VIS bit is 0, the vector 
held in the peripheral will be output without 
modification. 

While an interrupt source has an interrupt 
under service (IUS = 1), it prevents all lower 
priority interrupt sources from requesting 
interrupts by forcing IEO Low. When interrupt 
servicing is complete, the CPU must reset the 
IUS bit and, in most cases, the IP bit (by 
means of an I/O transaction). 
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Figure 4. Interrupt Connections 
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Interrupts 

(Continued) 
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IE 






STATE 6 

— I ♦ r^ L 

IEI | J INT | IEO 
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STATE 7 STATE 8 

Figure 5. State Diagram for an Interrupt Source 



Transition Legend 



[TV The peripheral detects an interrupt condition and sets 



Interrupt Pending. 



[oV All higher priority peripherals finish interrupt service, 



thus allowing IEI to go High. 



[qV An interrupt-acknow ledge transaction starts, and the 
L-'MEI/IEO daisy chain settles. 

FpVThe interrupt-acknow ledge transaction terminates with 
•""•^ the peripheral selected. Interrupt Under Service (IUS) 

is set to 1 , and Interrupt Pending (IP) may or may not 

be reset. 

H^VThe interrupt- acknowledge transaction terminates with a 
■—^ higher priority device having been selected. 

FpV The Interrupt Pending bit in the peripheral is reset by 
* m ~r an I/O operation. 

Tq\ A new interrupt condition is detected by the peripheral, 
*S causing IP to be set again. 

frj\ Interrupt service is terminated for the peripheral by 
*-/ resetting IUS. 

|lO IE is reset to zero, causing interrupts to be disabled. 

IjOIE is set to one, re-enabling interrupts. 



State Legend 

In 1 No interrupts are pending or under service for this 
^"""^ peripheral. 

I I I An interrupt is pendin g, a nd an interrupt reguest has 
^"^ been made by pulling INT Low. 

njl An interrupt is pending, but no interrupt reguest has 
^-^ been made because a higher priority peripheral has an 
interrupt under service, and this has forced IEI Low. 

I 3 j An interrupt-acknow ledge seguence is in progress, and 
L ~ J no higher priority peripheral has a pending interrupt. 

I'4 1 An mterrupt-acknowledge seguence is in progress, but 
a higher priority peripheral has a pending interrupt, 
forcing IEI Low. 

| g j The peripheral has an interrupt under service. Service 
may be temporarily suspended (indicated by IEI going 
Low) if a higher priority device generates an interrupt. 

\q I This is the same as State 5 except that an interrupt is 
also pending in the peripheral. 

Fn Interrupts are disabled from this source because IE = 0. 

jg 1 Interrupts are disabled from this source and lower 
^""^ priority sources because IE - and IUS = 1 . 



1 . This diagram assumes MIE = 1 . The effect of MIE = is the 
same as that of setting IE = 0. 

2. The DLC bit does not affect the states of individual interrupt 
sources. Its only effect is on the IEO output of a whole peripheral. 



3. Transition I to state 6 or 7 can occur from any state except 3 or 
4 (which only occur during interrupt acknowledge). 

4. Transition J from state 6 or 7 can be to any state except 3 or 4, 
depending on the value of IEI, IP, and IUS. 
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Interrupts 

(Continued) 



Bus 
Requests 



A peripheral's Master Interrupt Enable bit 
(MIE) and Disable Lower Chain bit (DLC) can 
modify the behavior of the peripheral's inter- 
rupt sources in the following way: if the MIE 
bit is 0, the effect is as if every Interrupt 
Enable bit (IE) in the peripheral were 0; thus 
all interrupts from the peripheral are disabled. 
If the DLC bit is 1 , the effect is to force the 
peripheral's IEO output Low, thus disabling all 
lower priority devices from initiating interrupt 



requests. 

Polling can be done by disabling interrupts 
(using MIE and DLC) and by reading per- 
ipherals to detect pending interrupts. Each 
Z-BUS peripheral has a single directly 
addressable register that can be read to deter- 
mine if there is an interrupt pending in the 
device and, if so, what interrupt source 
it is from. 



To generate transactions on the bus, a bus 
requester must gain control of the bus by 
making a bus request. This is done by forcing 
BUSREQ Lo w (Figure 6) . A bus request can be 
made only if BUSREQ is initially High (and has 
been for two clock cycles), indicating that the 
bus is controlled by the CPU and no other 
device i s request ing it. 

After BUSREQ is pulled Low, the Z-BUS 
CPU relinquishes the bus and indicates this 
co ndition by making BUSACK Low. The Low 
on BUSAC K is propagated throug h th e 
BAI/ BAO daisy chain (Figure 6). BAI follows 
BAO for components not requesting the bus, 
and any component requesting the bus holds 



its BAO High, thereby locking out all lower 
priority users. 

A bus requ ester gains control of the bus 
when its BAI input goes Low. When it is ready 
to relinquish th e bus, it stops pullin g BUSREQ 
Low and allows BAO to follow BAI . This per- 
mits lower priority devices that made simul- 
taneous requests to gain control of the bus. 
When all simultaneously re questing devices 
have relinquished the bus, BUSREQ goes 
High, returning control of the bus to the CPU 
and allowing other devices to request it. 

The protocol to be followed in making a bus 
request is shown in Figure 7. 



Z-BUS CM* 

BUSACK BUSREQ 



BUS 
REQUESTORS 



m 

IRS 



MS 




YES 




LOW 






| 




MSBBOS 








1 






TERMINATE U$£ 
RAISE BUSREQ 

twtwn 



f END 1 



Figure 6. Bus Request Connections 



Figure 7. Bus Request Protocol 
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Resource Resource requests are used to obtain control 

Requests of a resource that is shared between several 

users. The resource can be a common bus, a 
common memory or any other resource. The 
requestor can be any component capable of 
implementing the request protocol. 

Unlike the Z-BUS itself, no component has 
control of a general resource by default; every 
device must acquire the resource before using 
it. All de vices sh aring the general resource 
dri ve the M MRQ line (Figure 8). When Low, 
the MMRQ line indicates that the resource is 
being acquired or used by some device. The 
MMST pin allows e ach device to observe the 
state of t he MMR Q line. 

When MMRQ is High, a de vice ma y initiate 
a resource request by pulling M MRQ Lo w 
(Figure 9). The resultin g Low on MMRQ is 
propagated through the MMAI/MMAO daisy 

chain. If a d evice is not requesting the 

resource, its MMAO output follows its MMAI 
input. Any devic e making a resource 
request forces its MMAO output High to deny 
use of the resource to lower priority devices. 

A de vice gains control of the reso urce if its 
MMAI input is Low (and its MMAO output is 
High) after a sufficient delay to let the daisy 
chain settle. If the device does not obtain the 
resourc e after t his short delay, it must stop 
pulling MMRQ Low and make a nother request 
at some later time when MMRQ is again High. 
When a device that has gained control of a 
resource is finish ed, it releases the resource by 
allowing MMRQ to go High. 
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The four unidirectional lines of the resource 
request chain allow the use of line drivers, 
thus facilitating connection of components 
separated by some distance. In the case of the 
Z8000 CPU, the four resource request line s 
may be mapped into the CPU MI and MO pins 
using the logic shown in Figure 10. With this 
configuration, the Multi-Micro Request Instruc- 
tion (MREQ) performs a resource request. 
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Figure 9. Resource Request Protocol 

1 . For any resource requested, this wait time must be less than the 
minimum wait time plus resource usage time of all other 
requesters. 
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Figure 8. Resource Request Connections 



Figure 10. Bus Request Logic for Z8000 
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Test The timing characteristics given in this 

Conditions document reference 2.0 V as High and 0.8 V 
as Low. The following test load circuit is 
assumed. The effect of larger capacitive 
loadings can be calculated by delaying output 
signal transitions by 10 ns for each additional 
50 pF of load up to a maximum 200 pF. 



I 



FROM OUTPUT c 
UNDER TEST 




Open-Drain Test Load 



Standard Test Load 



DC 

Charac- 
teristics 


The following table states the dc character- 
istics for the input and output pins of Z-BUS 

Symbol Parameter 


components. All voltages 
ground. 

Min Max Unit 


are relative to 
Test Condition 




ViL 
VlH 

VlHRESET 

Vol 
Voh 
In. 

Id 


Input Low Voltage 
Input High Voltage 


-0.3 
2.0 
2.4 

2.4 
-10 
-10 


0.8 

Vcc + 0.3 

Vcc to 
0.3 

0.4 

+ 10 
+ 10 


V 
V 
V 

V 
V 
fiA 
M 






Input High Voltage on RESET pin 

Output Low Voltage 

Output High Voltage 

Input Leakage Current 

3-State Output Leakage Current in Float 


I L = 2.0mA 
Ioh = 250^A 
V IN = 0.4 to 2.4 V 
Vqut = 0.4 to 2.4 V 


Capacitance 


The following table gives maximum pin 
capacitance for Z-BUS components. Capaci- 
tance is specified at a freguency of 1 MHz 
over the temperature range of the component. 
Unused pins are returned to ground. 


Symbol 

C OUT 
Ci/o 


Parameter Max (pF) 

Input Capacitance 10 
Output Capacitance 15 
Bidirectional Capacitance 15 



Timing The following diagrams and tables give the 

Diagrams timing for each kind of transaction (except null 

transactions). Timings are given separately for 
bus masters and for peripherals and memories 
and are intended to give the minimum timing 
reguirements which a Z-BUS component must 
meet. An individual component will have more 
detailed and sometimes more stringent timing 
specifications. The differences between bus 
master timing and peripheral and memory tim- 
ing allow for buffer and decoding circuit 



delays and for signal skew. The timing given 
for memories is a constraint on bus-compatible 
memories (like the Z6132 Quasi-Static RAM) 
and is not intended to constrain memory sub- 
systems constructed from conventional com- 
ponents. 

Besides these timings, there is a reguirement 
that at least 128 transactions be initiated in any 
2 ms period. This accommodates memories that 
generate refresh cycles from Address Strobe. 
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Bus Master 
Timing 
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Parameters 1-25 are common to all transactions. 



I/O Transaction 
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Bus Master Number 


Symbol 


Parameter 


Min (ns) Max (ns) Notes 


Timing 










Parameters 




All Transactions 






1 


TpC 


Clock Period 


250 


2000 


2 


TwCh 


Clock High Width 


105 


1895 


3 


TwCl 


Clock Low Width 


105 


1895 


4 
5 


TfC 


Clock Fall Time 




20 
in 


IrL, 


- Olock luse lime ■ 




Z\j 


6 


TdC(S) 


Clock t To Status Valid Delay 




100 


7 


TdC(ASr) 


Clock 1 To AS t Delay 




90 


8 


TdC(ASf) 


Clock t To AS 1 Delay 




80 


9 
10 — 


TdS(AS) 


Status Valid To AS t Delay 

K r " 1 T \KT- 111 


50 

on 




IwAb 


Ao Low Width 


oU 




11 


TdDS(S) 


DS t To Status Not Valid Delay 


80 




12 


TdAS(DS) 


AS t To DS i Delay 


70 


2095 3 


13 


TsDR(C) 


Read Data To Clock 1 Setup Time 


50 




14 
15 


TdC(DS) 
-TdDS( AS) — 


Clock i To DS t Delay 
-DS t To AS 1 Delay 


. 7H 


70 


/U 




16 


TdC(Az) 


Clock t To Address Float Delay 




65 


17 


TdC(A) 


Clock t To Address Valid Delay 




90 


18 


TdA(AS) 


Address Valid To AS t Delay 


50 


1 


19 


TdAS(A) 


AS t To Address Not Valid Delay 


60 


1 


20 


TwA 


-Address Valid Width 


150- 




21 


ThDR(DS) 


Read Data To DS t Hold Time 







22 


TdDS(A) 


DS 1 To Address Active Delay 


80 




23 


TdDS(DW) 


DS t To Write Data Not Valid Delay 


80 




24 


TsW(C) 


WAIT To Clock 1 Setup Time 


50 


2,5 


25 


-ThW(C) 


-WAIT To Clock i Hold Time 

Memory Transactions 


o- 


2,5- 


26 


TdAS(W) 


AS 1 To WAIT Required Valid 




90 


27 


TdC(DSR) 


Clock i To DS (Read) i Delay 




120 


28 


TdDSR(DR) 


DS (Read) 1 To Read Data Required Valid 




185 


29 
30 


TwDSR 
— TdAz(DSR)- 


DS (Read) Low Width 
-Address Float to DS (Read) 1 Delay 


n 


250 


U 




31 


TdAS(DR) 


AS t To Read Data Required Valid 




320 


32 


TdA(DR) 


Address Valid To Read Data Required Valid 




400 


33 


TdC(DSW) 


Clock i To DS (Write) 1 Delay 




95 


34 


TwDSW 


DS (Write) Low Width 


160 




35 


TdDW(DSWf) -Write Data Valid To DS (Write) i Delay 


50- 




36 


TdDW(DSWr) Write Data Valid To DS (Write) I Delay 


230 








I/O Transactions 






37 


TdAS(DR) 


AS t To Read Data Required Valid 




570 


38 


TdA(DR) 


Address Valid To Read Data Required Valid 




650 


39 


TdAz(DSI) 


Address Float To DS (I/O) i 







40 


-TdC(DSI) — 


Clock i To DS (I/O) 1 




120 


41 


TdDSI(DR) 


DS (I/O) 1 To Read Data Required Valid 




320 


42 


TwDSI 


DS (I/O) Low Width 


400 




43 


TdDW(DSIf) 


Write Data To DS (I/O) i Delay 


50 




44 


TdDW(DSIr) 


Write Data To DS (I/O) t Delay 


480 




45 


TdAS(W) 


-AS t To WAIT Required Valid 

Interrupt-Acknowledge Transactions 




340 


46 


TdAS(DSA) 


AS t To DS (Acknowledge) 1 Delay 


960 




47 


TdC(DSA) 


Clock t To DS (Acknowledge) 1 Delay 




120 


48 


TdDSA(DR) 


DS (Acknowledge) i To Read Data Required Valid 




420 


49 
50 


TwDSA 
-TdAS(W) 


DS (Acknowledge) Low Width 

n f 4 T T A r . • l It _1 T T 1 1 


485 


r\ An, 


Ab 1 lo Wait Required Valid. 




o4U 


51 


TdDSA(W) 


DS (Acknowledge) i To Wait Required Valid 




130 



1 . Timing for extended addresses is CPU dependent; however, extended addresses must be valid at least as soon as addresses are valid on 
ADq-ADj5 and must remain valid at least as long as addresses are valid on ADq-AD^. 

2. The exact clock cycle that wait is sampled on depends on the type of transaction; however, wait always has the given setup and hold times to 
the clock. 

3. The maximum value for TdAS(DS) does not apply to Interrupt-Acknowledge Transactions. 

4. Except where otherwise stated, maximum rise and fall times for i nputs are 200 ns. 

5. The setup and hold times for WAIT to the clock must be met. If WAIT is generated asynchronously to the clock, it must be synchronized 
before input to a bus master. 
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Memory and 

Peripheral 

Timing 
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C8014-0183 C8014-0188 C8014-0192 



Memory and Number 


Symbol 


Parameter 


Min (ns) Max (ns) 


Notes 


Peripheral 












Timing 
Parameters 


TsCS(AS) 


All Transactions 

CS To AS t Setup Time 







1 




ThCS(AS) 


CSToASj_HoldTime 


60 




1 


3 


TsS(AS) 


Status To AS t Setup Time 


20 




2 


4 


ThS(DS) 


Status To DS t Hold Time 


60 






5 


-TsA(AS) 

ThA(AS) 




10 




1 


6 


Address To AS t Hold Time 


50 




1 


7 


TwAS 


AS Low Width 


70 






8 


TdDS(DR) 


DS t To Read Data Not Valid Delay 









9 

10 — 
11 


TdDS(DRz) 

-TdAS(DS) — 

TdDS(AS) 


DS t To Read Data Float Delay 
21° t t - n n i n l^u 


fin 


70 
—2095 


5 


DSt To AS 1 Delay 


ou 
50 


12 


ThDW(DS) 


Write Data To DS t Hold Time 

Memory Transactions 


30 




1 


13 


TdA(DR) 


Address Required Valid To Read 
Data Valid Delay 




340 




14 


TdAS(DR) 


AS t To Read Data Valid Delay 




230 




15 


-TdAz(DSR)- 


- Address Float To DS (Read) i Delay 









16 


TdDSR(DR) 


DS (Read) I To Read Data Valid Delay 




95 




17 


TwDSR 


DS (Read) Low Width 


240 






18 


TwDSW 


DS (Write) Low Width 


150 






19 
20 


TsDW(DSWf) 
— TcnwYnQwv 


Write Data To DS (Write) 1 Setup Time 


30 
9in 






ISUVV^JJoVVr; wine j-/cua iu i^o v* VIiLeJ / ' otsiup nine 












I/O Transactions 








21 


TdA(DR) 


Address Required Valid To Read Data 
Valid Delay 




590 




22 


TdAS(DR) 


AS t To Read Data Valid Delay 




480 




23 


TdDSI(DR) 


DS (I/O) i To Read Data Valid Delay 




255 




24 


TdAz(DSI) 


Address Float To DS (I/O) 1 Delay 









25 


-TwDSI 


- DS (I/O) Low Width 


-390 — 






26 


TsRWR(DSI) 


R/W (Read) To DS (I/O) i Setup Time 


100 






27 


TsRWW(DSI) 


R/W (Write) To DS (I/O) i Setup Time 









28 


TsDW(DSIf) 


Write Data To DS (I/O) 1 Setup Time 


30 






29 


TsDW(DSIr) 


Write Data To DS (I/O) t Setup Time 


460 






30 


-TdAS(W) 


- AS t To WAIT Valid Delay 


195 








TsIA(AS) 


Interrupt-Acknowledge Transaction! 


9 








31 


INTACK To AS t Setup Time 




32 


ThlA(AS) 


INTACK To AS t Hold Time 


250 






33 


TdAS(DSA) 


AS t To DS (Acknowledge) 1 Delay 


940 






34 


TdDSA(DR) 


DS (Acknowledge) i To Read Data 
_Vahd Delay 


360 






35 


-TwDSA 


- DS (Acknowledge) Low Width 


-475 — 






36 


TdAS(IEO) 


AS 1 To IEO 1 Delay 






3, 4 


37 


TdlEIf(IEO) 


IEI To IEO Delay 






4 


38 


TsIEI(DSA) 


IEI To DS (Acknowledge) i Setup Time 






4 



1 Parameter does not apply to Interrupt-Acknowledge Transactions 

2. Does not cover R/W for I/O Transactions 

3. Applies only to a peripheral which is pulling INT Low at the beginning of the Interrupt-Acknowledge Transaction 

4 These parameters are device dependent The parameters for the devices in any particular daisy chain must meet the following constraint- 
for any two peripherals in the daisy chain, TdAS(DSA) must be greater than the sum of TdAS(IEO) for the higher priority peripheral, 
TsIEI(DSA) for the lower priority peripheral, and TdlEIf(IEO) for each peripheral separating them in the daisy chain. 

5 The maximum value for TdAS(DS) does not apply to Interrupt-Acknowledge Transactions 

6 Except where stated otherwise, maximum rise and fall times for inputs are 200 ns. 
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Design Engineering 



Z-bus and peripheral support packages 
tie distributed computer systems together 



To couple support circuits to Z8000 microprocessors 
in an organized manner, an interconnection 
philosophy is needed. To this end, Zilog has developed 
the shared Z-bus— not a device, but a concept— to 
allow the construction of complex configurations of 
peripherals with program interfaces. This article 
takes the reader a step beyond basic interfacing 
circuits (ELECTRONIC DESIGN, Oct. 25, 1979, p. 90) and 
introduces both the Z-bus concept and a new family 
of peripheral packages, designed especially for the 
Z8000 /aPs. Future articles will explore Z8000 software. 



The Z-bus logically and efficiently organizes in- 
terconnections and transactions between Zilog's 
Z8000 microprocessors and their peripherals. The 
signals in transactions between microprocessors and 
peripherals inherently provide all the necessary tim- 
ing, allowing asynchronous operation, so that the 
peripheral devices can be independent of the 
processor's speed and clock frequencies. In addition, 
the bus has a simple scheme— the daisy chain— for 
establishing sequential priority, as when a common 
system resource must be shared by several processors 
and peripherals. 

Processors and peripherals engage in five types of 
transactions through the Z-bus: 

■ Memory transfers. 

■ I/O transfers 

■ Interrupts requests, to interrupt the Z-bus proc- 
essor. 

■ Bus requests, to gain control of the bus for both 
memory and I/O transfers 

■ Resource requests, to gain access to a general 
resource. 

Although memory and I/O transfers are usually 
between the Z-bus processor and the memory or a 
peripheral, some Z-bus-system peripherals, such as a 
direct-memory-access controller can initiate transfers 
after making a successful bus request. 

The Z-bus system depends on strobe, request and 
acknowledge signals to provide the timing information 



between processor and peripherals (see Z-bus signal- 
description table). The multiplexed address/data 
lines, when combined with a low AS (address strobe) 
signal, carry the addresses of memory or internal 
registers within peripheral-interface packages or pe- 
ripheral devices. When combined with a lowDS (data 
strobe) the multiplexed address/data lines transfer 
data from_or to the registers, depending on the state 
of the R/w (Read/Write) line. 




1. Bus-request signals to the mas ter processor from all 
requestors are or- wired to the BRQ line, and their baT/bao 
lines are daisy chained to provide a priority sequence (a). 
The daisy-chain signal is derived from the BUSACKsignal 
delivered by the master processor (b). 



John Banning, Manager of Component Architecture, Zilog, 
Inc., 10460 Bubb Rd., Cupertino, CA 95014. 



Reprinted with permission of Electronic Design . 
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Data can be formatted in 8 or 16-bit groups, with 
memory and I/O addresses that are 16-bits long 
(memory addresses in the Z8001 segmented version 
can be as long as 24 bits). 

Peripherals get on the bus 

For a peripheral to get control of the bus, theBUSRQ 
line of the Z-bus processor in the system must be 
driven low. When ther e are s everal peripherals, the 
easiest way to generate BUSRQ is to wire-OR all poten- 
tial bus request signals together (Fig. la) via the Z- 
bus BRQ line, which then becomes BUSRQ at the process- 
or port. 

With BUSRQ low after the completion of any system 
cycle, the processor generates a BUSACK low output 
(Fig. lb) to acknowledge the release of the bus. At 
this time, all the processor outputs go into a high- 
impedance state to avoid affecting other signals on 
the bus. Meanwhile, BUSAK's low propagates through 
a daisy-chain hookup (Fig. la) among the bus re- 
questors—the low enters each unit's BAT and leaves 
via its BAO port. The device that requested control of 
the bus begins to use it; but the device's BAO remains 
high, preventing lower priority bus requesters from 
using the bus and providing a signal that identifies 
it as the requestor. When the device completes its use 
of the bus, BUSRQ returns to high, followed one cycle 
later by a high BUSAK and BAT. This indicates that the 
Z-bus processor again controls the bus. 

Clearly, the Z-bus processor occupies a special place 
on the bus, even though the processor, like any other 
device in the system, must wait until the bus is 
released before regaining control. 

However, when peripherals that have intelligence 
and programmability approaching that of a processor 
share the bus, the management protocol must be more 
equitable than in a master-slave relationship. A pro- 
tocol should be available that allows any intelligent 
component on the bus to seize a common resource of 
the system— a peripheral, memory, modem, display, 
etc. 

An equal-opportunity protocol 

Unlike the bus-request protocol, the resource-re- 
quest chain is not dominated by a single system 
component. To acquire a resource, a component must 
issue a request signal, MMRQ low. All MMRQ signals 
for a given resource are wire-ORed to a common bus 
line (Fig. 2a). Nevertheless, the resource-requesting 
devices are daisy-chain connected, so that a low on 
the MMRQ line propagates through the chain— into 
each MMAI and out of each MMAO. However, the MMAO 
of the requesting device remains high. Thus, the 
combination of MMRQ low and MMAO high in a device 
identifies it as the temporary controller of the re- 
source. 

Before a component makes a resource request, it 
first checks the MMST (resource-status) line to see if 



the resource is busy. A low MMST line indicates busy, 
and additional MMRQs are blocked. No requestor can 
preempt another, but when simultaneous requests are 
made for the same resource, the requestor highest on 
the daisy chain will seize the resource first, all else 
being equal. 

If MMST is high, however, MMRQ activates the line. 
After a finite delay, if MMAI also goes low, the resource 
has been seized successfully and the intended trans- 
action can begin. Otherwise, the request is aborted 
— because another requester higher on the daisy chain 
had already seized the resource. The preempted re- 
quester may retry immediately or after some delay. 

A simple logic circuit can take advantage of a 
requestor's low MMRQ and MMAI and its high MMAO to 
enforce access protection for both the resource and 
the requestor that has successfully seized the resource. 

At this point, the designer might notice that, al- 
though four lines are used on the Z-bus to control 
resource requests, the Z8001/8002 processors provide 
just two pins Mo and Mj. On its Multimicro Output 
(Mo) pin, the ixF issues a low signal to request a 
resource; its Multimicro Input (Mi) pin tests to de- 
termine the state of the resource. 

To get onto the daisy-chain with other requestors, 
MMAI and MMAO pins are also needed. A logic circuit, 
as in Fig. 2b, can provide the interface for the 



resource 
requestors 



'"SHBSP-- 



MW? 

mm 

MMAO 
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MMRQ 
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^j^m i i^ : 



MMAI 
MMST 
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CU 



WRED-OR 



MMRQ 
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-MMAO 



2. The resource-request chain, like the bus-request, also 
OR-wires the request signals, in this case MMRQ,and daisy- 
chains for priority (a). Severai gates, however, are needed 
to interface a Z8000, which has just two resource-request 
ports, M and M, , with the daisy chain (b). 
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Z8001/8002 processors: MMAI passes through gate G 4 
to MMAO as long as Mo is high (not requesting the 
resource). While Mo is high (before making a request), 
the state of the MMST line passes through Gi and G 2 
to M T . With M, high (mmst is not busy), M can issue a 
request. But if another requestor higher had seized 
the resource first, MMAI would be low and would pass 
through Gi and G 2 to Mj to abort the ^Fs request, 
until it could try again. 



Interrupts also are daisy chained 

In the interrupt protocol (as in both the bus-request 
scheme and the resource-request scheme), the device's 
physical position in the daisy-chain— in at IEI, out at 
IEO— determines its priority. Also, like bus requests, 
interrupt requests are directed to the processor— in 
this case, to one of its three interrupt input ports— 
NMI, vi, or nvi. A separate set of interrupt-protocol 
signals— int, intack, iei and ieo —control each /zP 
interrupt mode that is used. The peripheral INT ports 
receive the same treatment as BRQ —the INT lines for 
one of a processor's interrupt modes are all wire-ORed 
together (Fig. 3a). The appropriate acknowledgement, 
decoded from the four status lines of the /uP (Fig. 3b), 
returns via the Z-bus' INTACK line to all the daisy- 
chained peripheral requestors. This procedure tem- 
porarily inhibits further interrupt requests. 







Although more than one peripheral may have issued 
an interrupt request simultaneously, the request 
highest on the daisy chain prevails: Its IEO remains 
low, aborting any other interrupt requests further 
down the chain, until IEO drops low. 

Three Wait cycles occur after the leading edge of 
INTACK to allow the daisy chain to settle (or more, 
if a peripheral device asks for it via the WAIT line). 
Then, a DS from the ixP stimulates the interrupting 
peripheral to place its data on the bus. INTACK returns 
high two (or more) Wait cycles later, after completion 
of the transaction for which the interrupt was ini- 
tiated. 

After INTACK returns high, any requestor on the 
daisy chain can issue an interrupt; lower-priority 
devices are locked out until higher priority interrupts 
have been serviced. 



I/O is main transaction 

The main purpose of an interrupt request is to 
perform a transfer of information in or out of the 
processor. This I/O transaction is distinquished from 
every other by the /uP's status-lines code 0010, desig- 
nated I/O Reference. 

The bus R/W line determines the direction in which 
the information flows: The processor reads from the 
requestor device when R/W is high or writes into the 
device when R/W is low. Information flows via the 
AD to AD 15 lines of the ixF. 

When AS is low, the information being transferred 
is addresses; when DS is low, the information is data. 
Word or byte formats are identified by the B/W line 
—word format, when low — allowing 16 or 8-bit data 
elements (Fig. 4). 

This early-status information, which defines the 
transaction ahead of the actual process, allows the 
enabling of bidirectional drivers and other interface 
hardware elements. The enabling action is a distinct 
benefit, which simplifies interfacing peripherals. 
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3. Microprocessor interrupts from peripherals also use 
an or- wired line (int) for initiating the sequence and a daisy 
chain to establish peripheral priorities for a given type 



of interrupt (a). The properly decoded status lin e of tha t 
interrupt from the processor then becomes the intack 
signal on the line (b). 
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Indeed, the Z8000 processors distinguish between 
I/O-transaction and memory/processor-interchange, 
modes only by using different status-line codes; other- 
wise, the two modes work almost the same way. The 
address/data bus, strobe lines AS and ds; and theR/W, 
B/W, and N/S lines are shared by both I/O and 
memory transactions; therefore the interface buffers 
can be shared by substantially fewer processor pins. 

One difference in the modes— an extended address 
capability to 23 bits— applies only to memory, when 
the segmented Z8001 version of the processor is used. 

Memory is organized into two 8-bit-wide banks. One 
bank contains the most-significant bytes of the ad- 
dressable words; the other contains the lower bytes. 
The banks can be activated together or separately by 
a B/W low signal (Fig. 4). 

Memory and I/O functions must then be done 
sequentially, but the high-speed of the processor 
transactions can handle most applications adequately. 
If necessary, the wait line can be called upon to extend 
a transaction for I/O and memory, because the device 
(or memory) is not ready or cannot work fast enough 
to keep up with the processor. 

Help for the busy processor 

When the processor gets too busy to handle all its 
peripherals efficiently, then Zilog's Universal Per- 
ipheral Controller (Z-UPC), one of several support 
packages that will soon be available, can step in and 
help out ( Fig. 5). With pin f unctions AS" and PS, R/W 
and WAIT, iei, and IEO, INT and INTACK, Z-UPC can plug 
right into the Z-bus and serve as a complete slave 
microcomputer for distributed processing. It can: 

■ Control peripheral devices with internal ROM or 
RAM instructions. 

■ Manipulate data arithmetically or format buffer 
data in internal registers. 

Based on the Z8 microprocessor architecture and 
instruction set, the Z-UPC is an intelligent device that 
can unburden the main processor and greatly increase 
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4. The byte/word and read/write organization of words 
is handled almost the same way for I/O transactions 
between peripherals and processor as for I/O transactions 
between memory and processors. 



Z-Bus signal descriptions 
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M\, 



DS 

EXTENDED 
ADDRESSES 

TNT, 
INTACK, 
IEI, IEO 



RESET 
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WAIT 



MMST, 
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Address/Data Lines. The multiplexed 
address/data lines are used for both 
I/O and memory transfers. 

Address Strobe. The rising edge of AS 
indicates addresses are valid. 

Bus Request, Bus Acknowledge Input, 

Bus Acknowledge Output. Other 

Z-Bus masters, such as the Z-DMA, 

use 

this bus control request chain to 

take control from the CPU. 

Data Strobe. DS times the data in and 
out of the CPU. 

The number, type and nature of these 
lines depend on the CPU used. 

Interrupt, Interrupt Acknowledge, 
Interrupt Enable Input, Interrupt 
Enable Output. This set of lines is 
used for interrupt control and the 
interrupt daisy chain for each type 
of interrupt. 

Reset. A Low on this line resets the 
system. 

Read/Write. R/W indicates the CPU is 
reading or writing. 

The status lines distinguish the dif- 
ferent kinds of bus transactions, such 
as I/O or memory. 

Wait. This line indicates to the bus 
controller that the responrier is not 
ready for data transfer. 

MMRQ Multi-Micro Status, Multi-Micro Re- 
MMAI quest, Multi-Micro Acknowledge 

Output, Multi-Micro Acknowledge In- 
put. This resource-request chain 
controls access to common 
resources. 
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overall system efficiency and speed. It generates 
almost any control signal that a peripheral device 
might need. Operating on the same 4-MHz clock as 
the Z8000 /aPs, it executes instructions in an average 
of just 2 j*s. 

Not only speed, but flexibility is attained. An 
extensive register file of 256 byte-registers, organized 
into 16 groups of 16 working registers each make the 
Z-UPC very versatile. Short-format instructions ex- 
pedite the access to any group. The file includes 234 
general-purpose, 19 status-and-control (including two 
16-bit counter/timer) and three I/O-port registers. 
Add six levels of priority interrupts and the Z-UPC 
is indeed a flexible support package. 

Any general-purpose register can be used as an 
accumulator, address pointer, index register or 
stack for the the Z-UPC's program. All unused 
general-purpose registers can then act as data buffers 
between the master processor and the peripheral 
device. In addition, communications between the mas- 
ter processor and the Z-UPC takes place via one of the 
groups of 16 registers, which are accessed directly by 
the master processor over the Z-bus Address/Data 
(AD X ) lines. 

Examining the I/O ports 

The Z-UPC's three I/O ports also allow great flex- 
ibility. Two of the I/O ports are 8-bits each; the third 
has 8 bits for I/O that can be shared between I/O and 
control lines, as determined by the program. In fact, 
all the I/O ports can be programmed in many combina- 
tions as input, output or bidirectional lines, with or 
without a handshake protocol. 

When its P3 , P3 2 , p3 5 and P 3 7 pins are programmed 
aslEl/lEO, INTACK and INT lines, the Z-UPC fits easily 



into the Z-bus's daisy-chain priority system. As an 
alternative, the controller can be programmed to 
operate with a polled system— a concept that is also 
compatible with the Z-bus. 

Not all peripheral interfacing tasks need all the 
intelligence and flexibility that the Z-UPC possesses. 
Zilog's Counter/Timer and Parallel I/O (Z-CIO), with 
its two independent 8-bit bidirectional I/O ports and 
special-purpose 4-bit I/O port, can satisfy most or- 
dinary needs for parallel I/O interfacing and 
counting/timing (Fig. 6). 

Either of the Z-CIO's two identical 8-bit I/O ports 
can operate in a handshake-byte or bit-by-bit mode. 
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6. By taking care of parallel I/O interfacing and counting, 
the Z-CIO peripheral-interfacing circuit chip can remove 
a heavy burden from the processor in a complexZ8000 
system. 
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5. A universal peripheral controller (Z-UPC) can take a 
great amount of the load off a microprocessor, especially 



when the processor is interfacing peripheral devices that 
demand a lot of detailed attention. 
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7. For long-distance serial communications with a 
processor, the Z-SCC converts parallel-to-serial data and 



then serial-to-parallel for either synchronous or 
asynchronous data links. 



In the later mode, the direction of each bit can be 
individually programmed. Like the universal con- 
troller, the two ports can perform in the handshake 
mode, as inputs, outputs or bidirectional lines; also, 
they can be linked into one 16-bit port. In addition, 
each of the 8-bit ports includes pattern-recognition 
logic to generate an interrupt when a specified pattern 
is detected. 

Pour handshake protocols are available: the 
IEEE-488, an interlocked (with another Z-CIO or Z- 
UPC), a strobed and a pulsed. 

The pulsed handshake connects one of the Z-CIO's 
counters with logic, to interface a mechanical device 
such as a printer. The special-purpose 4-bit I/O port 
provides the handshake controls: a Wait/Request line 
for high-speed data transfer or general-purpose I/O. 
The programming and status for all the control 
features reside in 12 registers provided for each port. 

The Z-CIO's three, independent, identical 16-bit 
counter/timers (two of the counters can be pro- 
grammed to form a 32-bit counter/timer) can help to 
control a device. Each counter/timer consists of a 16- 
bit down-counter and four registers as follows: a 16- 
bit register, to hold the initial value (called the Time 
Constant), which is loaded into the down-counter; 
another 16-bit register, to hold a current down-count 
output, when strobed; and two 8-bit registers to hold 
mode, control and status information. 

Either the counting or the timing function can be 
programmed for single-cycle (one-shot) or continuous 
operation with a pulse or square-wave output. Up to 
four control lines— for .each counter/timer— can act 
as the counter input, enable input, trigger input and 
counter/ timer output, as required. 

Whether counting or parallel interfacing, the Z-CIO 
can substantially unburden the master processor in 
a computer system, especially when complex per- 
ipherals demanding high service must be handled. The 
Z-CIO is also fully compatible with the Z-bus and 



provides the full complement of bus control signals 
and daisy-chain priority pins (IEI/IEO). 

Serial unit supports many protocols 

Also supporting the Z-bus family is the Z-SCC, 
Serial Communications Controller, a peripheral-in- 
terfacing package for serial communications or data- 
transfer applications (for example, with disks and 
cassettes). The package contains two independent full- 
duplex channels, each with its own quartz-crystal 
oscillator, baud-rate generator and digital phase- 
locked loop for clock recovery (to 1 Mbit/s). Each 
channel also provides facilities for modem/control 
(Fig. 7a). 

The Z-SCC is programmable for NRZ, NRZI or FM- 
data encoding. A channel in an asynchronous mode 
can operate with 5 to 8-bit codes per character plus 
1, 1-1/2 or 2 bits per character as stop bits. In addition 
the package provides such features as break detection 
and generation, and parity, overrun and framing error 
detection. 

In the synchronous mode, the Z-SCC handles such 
protocols as IBM Bisync or bit-oriented HDLC and 




8. The Z-FIO general-purpose bidirectional buffer can 
interconnect devices operating at different speeds. It is 
not limited to Z8000 configurations, but can handle 
almost any general-purpose n? system. 
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SDLC with frame-level control, automatic zero-inser- 
tion and deletion, I-field residue handling, abort 
generation and detection, CRC generation and check- 
ing and loop-mode operation. Parity and overrun 
features also apply to synchronous operation 

Fig. 7b shows one of the Z-SCC's channels connected 
as a synchronous data-link— the loop (SDLC) mode. 
Note the absence of clock lines. With NRZI or FM 
data, no clock lines are needed, since the clock can 
be recovered at the receive end from the bit stream 
by the Z-SCC's digital phase-locked loop. The other 
channel, via a modem under control of the Z-SCC, is 
shown servicing an asynchronous serial port. 

Basically the Z-SCC functions as a parallel-to-serial 
and serial-to-parallel converter, but it does more: Its 
sophisticated repertoire of internal functions greatly 
reduces the amount of external supporting logic 
needed for a wide variety of serial-communications 
applications in distributed-processing systems. 

Another great saver of external assorted logic in 
distributed-processor operation is the Z-FIO general- 
purpose bidirectional buffer. 

First-in, first-out 

The Z-FIO can interconnect components or sub- 
systems (of almost any /xP including the Z8000) 
operating at different speeds. It can accept 128 bytes 
of data, which it then holds until they are called for 
by another device in the system. In this way, interrupt 
servicing time can be cut two orders of magnitude in 
most I/O transactions. Moreover, the capability of 
moving variable-sized blocks under either direct- 
memory access or interrupt control greatly facilitates 
system throughput, which is especially important 
with fast peripheral circuits. 

The internal functions of the Z-FIO are shown in 
Fig. 8. Its two sets of Address/Data ports are identical 
except for programming. The A set (programmed by 
pins M and M^ and the B set (programmed by bits 
SL and SLO have in common a 128 X 128 RAM for 
data storage, two 7-bit counters and several registers. 

The RAM can read and write both simultaneously 
and independently: The A set can write a byte of data 
into the RAM without disturbing a simultaneous read 
operation at the B set. The counters address the RAM 
and, by means of a subtractor, determine the number 
of bytes remaining in the memory. This number can 
be read from a status register dedicated to each set. 

When compared internally with the memory-status 
register, a programmable register generates an inter- 
rupt for starting and stopping DMA transfers. Anoth- 
er pair of registers permits direct communication 
between the ports by bypassing the main buffer 
memory. ■■ 
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1 INTRODUCTION 

This printer driver was written to suit a variety of applications, 
but in particular, it was prepared to be used as a companion to the 
Zilog text formatting utility, ZFORM. 

It is also well suited to applications requiring the printing of long 
lines, such as are found in connection with business orientated data 
base management programs. 

It provides compatibility with both of the most commonly used high 
performance, high quality printers, the NEC SPINWRITER, and the 
DIABLO . 

The features provided by the driver ensure that the printer operates 
at its maximum possible speed under all circumstances. Adjacent 
spaces and tabs are merged into single head movements, and the 
printing direction is fully optimised to minimise unnecessary head 
travel. This has the effect not only of raising print speeds, but of 
considerably reducing noise and vibration, although this effect will 
not be obvious unless two printers are operating near to each other 
under different control algorithms. 

Several further features are controlled by "attributes" which could 
be easily extended, but as currently implemented allow for 
underlining , BOLD character printing, RED printing, su P er scripting , 
and .scripting, or any combination of these features , which can 
even Be invoked at the character level within words. 

The driver can optionally skip to top-of-page at a given page line 
count, to prevent printing over fold lines in continuous stationery, 
and , if required will allow the operator to load a fresh sheet of cut 
paper after ejecting the current "page". In this case, a message is 
sent to the operator console, together with a bell-code, as 
indications that operator intervention is required. When the new 
sheet has been loaded , the operator presses a key on the console in 
order to continue printing. In this situation, the operator is able 
to give a specific response in order to inform the driver that pauses 
are no longer needed between pages. This response is given by 
pressing either upper-case , or lower-case C ( for .Continue ) . 

The facility for using cut sheets is essential in the context of 
preparing documents such as letters, which will usually be printed on 
headed paper for the first sheet, and plain paper for continuations. 

The printing operation may be aborted at any time by hitting the 
<ESC> key on the console, and may be halted temporarily at any time 
by raising the cover on the printer itself. 

If the printer is equipped with a detector for end-of-ribbon, which 
is a standard feature of the SPINWRITER, it will automatically pause 
for the operator to load a new cartridge. Printing will be 
suspended, and an audible alarm given to indicate that operator 
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intervention is required . After the cartridge has been replaced , 
printing resumes without any visible discontinuity. 



2 THE DRIVER FROM A NON TECHNICAL USER'S VIEWPOINT 



2.1 LOADING AND INITIALISING THE DRIVER 

The driver is loaded by RIO, the operating system executive, either 
in response to a direct command from the operator entered at the 
console keyboard , or to a command included in a file containing 
commands, such as the file OS.INIT . 

In either case, the operation involves the use of the RIO command 
ACTIVATE. 

Assuming that a NEC Spinwriter is in use, and the files of the disc 
supplied have been used without modification, the actual device 
driver will be known as $NEC. The command is therefore 

^ACTIVATE $NEC 

RIO prompt 

0p erator command 

Optionally, the operator may make the printer driver known by a 
'.Logical Unit Number* , preferably 3, which is used by convention for 
printers. This can be achieved by the additional command :- 

^DEFINE 3 $NEC 

RIO prompt 

pera t or command 

There are several RIO utilities, such as PRINT, and CAT, which 
automatically send their output to whatever device has been 
associated with LUN=3, and it is recommended that the procedure given 
above be used. This adds significantly to the general convenience of 
using the system. 

When the driver receives an Initialisation request from RIO, it 
performs some general housekeeping operations, such as preparing the 
electrical characteristics of the hardware interface to the printer, 
and placing the printhead in a known position, and then it sends a 
message to the operator, asking whether it is to operate in the 
manner needed if cut sheets of paper are to be used, and whether it 
is to automatically perform paper throws to prevent printing over 
folds in continuous stationery. These two functions are separately 
controllable, as some programs which use the printer driver perform 
similar functions themselves. In that case, irritating interactions 
could possibly occur, resulting for example, in alternate pages being 
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completely blank. Initialisation requests are sent to the printer 
driver whenever it is ACTIVATEd, or, if required, can be issued 
specifically on demand by the operator by using the command:- 



Jl $NEC 



RIO prompt 

Operator command 



In either event, the driver will introduce itself by a message on the 
system console , giving its revision level, and will then ask the 
operator two questions. The responses are entered on the console 
keyboard as single characters. The response character Y in either 
upper, or lower case, specifies 'YES 1 to the question. 

The dialogue takes the following form:- 

JACTIVATE $NEC 

Printer Driver rev . 2.1 

Cut sheets ? Y 
Auto formfeed ? Y 



In the above example, the two responses for Yes are shown. Any other 
character response apart from Y is interpreted as NO. 

If the requirements of the driver change during a session, all that 
is needed to redefine the characteristics is for the operator to give 
the command to re- initialise the driver, as exampled previously. The 
two questions will be re-asked. If this is done, it does NOT alter 
the previously defined association between the driver and a RIO LUN. 



2.2 USING THE DRIVER 

RIO can be told to pass data ( ie. text ) to the printer in 
essentially two different ways. One is much simpler to use than the 
other, and relies on having DEFINEd that the driver is known to RIO 
as LUN=3. 

Assuming that a file is known to exist, such as PRINTER. DRIVER. MANUAL 
and that the printer driver is indeed known as LUN=3, all that the 
operator needs to enter is:- 

JPRINT PRINTER. DRIVER. MANUAL 

and the contents of that file will be printed. Obviously the text 
actually appearing on the paper will largely reflect exactly what is 
contained in the file, but pagenation can be affected by whether the 
operator has selected automatic formfeed. The use of cut sheets does 
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not affect the printed output, merely the type of paper stock which 
can conveniently be used. 

Alternatively it is often possible to send text direct to $NEC as it 
is being generated, instead perhaps, of preparing a file which would 
have to be printed subsequently. 

This can be achieved in different ways depending on the program which 
is generating the text. As an example, we will show the use of 
ZFORM. 

ZFORM outputs its formatted text to the system console unless the 
operator specifies an alternative. This is particularly convenient, 
as most operators would require to view the fully formatted text on 
their VDU more frequently than actually printing it. 

An alternative is specified by giving an "0=" option, which can 
define either the name of a file which is to be prepared to contain 
the formatted output text, or a driver, such as $NEC. In this case, 
the formatted text would be sent directly to $NEC, and therefore to 
the printer, as it is being generated. 

For example: 

JZFORM PRINTER. DRIVER. MANUAL 0=$NEC 



2.3 AUTOMATIC FORMFEED 

If the operator has selected the automatic formfeed option, after 
printing a given number of lines on a page, the driver will tell the 
printer to perform a paper-throw, ie. formfeed operation, which 
prepares it to start printing on a new sheet. 

The driver maintains a count of the number of lines it has printed 
since the last time it started a new sheet, and when it reaches 63 
(this can be varied if necessary) it requests a formfeed. As most 
paper sheets have a length equal to 66 lines, this means that every 
page would have at least three blank lines, and they would normally 
be positioned to bracket the folds in continuous stationery. 

However, if the driver finds a formfeed code in the text being 
printed, it requests a paper throw, and zeros its line counter. 

Most files of text which are prepared by Zilog utility programs do 
contain embedded formfeed codes, and it is for this reason that the 
driver usually does not need to insert any automatically. 
Interaction could occur if the text being printed were pagenated 
using the same line count per page as the printer driver. Blank 
alternate pages would result. 

It is very useful, however, to be able to neatly print, and pagenate, 
files which are prepared directly by an operator using a text editor, 



6-9 



Spinwriter /Diablo driver Revision 2 . 1 



such as input files for use by ZFORM for example, and it is then that 
the auto formfeed option is likely to be used. 



2.4 USE OF CUT SHEETS 

If the operator has selected the cut sheet option, whenever the 
driver has sent a paper throw instruction to the printer, which will 
cause the current sheet to be ejected, it will then cause the 
console's buzzer to be sounded and send a message to the operator at 
the system console. The message represents a request to load a new 
sheet of paper, and then to press a key on the keyboard as an 
instruction to the driver that printing can resume. If any key other 
than either an upper case, or a lower case C is pressed, the driver 
will continue to request the loading of fresh sheets whenever it has 
ejected the current sheet. However, if the letter C is used in 
response , printing will continue in the expectation that continuous 
stationery is then in use. 



2.5 CHARACTER ATTRIBUTES 

As implemented herein, the attributes of BOLD, UNDERLINE, RED, 
SUPERSCRIPT, and SUBSCRIPT, are invoked by two-character "ESCAPE code 
sequences" in the text being printed, employing codes which do not 
correspond to printable characters. 

This technique ensures that text files which contain the necessary 
control codes for these functions can be printed by printers such as 
TALLY, CENTRONICS etc. and by conventional Visual Display Units when 
handled by standard" Zilog drivers, with total compatibility. 
Obviously these peripherals cannot produce the effects obtainable 
when using a Spinwriter, but the text format and content would be the 
same. It would perhaps be regarded as a draft quality output which 
can be prepared at very high speed. 

The attribute control sequences are as follows: 

BOLD <ESC> CTRL-B 

UNDERLINE <ESC> CTRL-U 

RED <ESC> CTRL-R 

POSITIVE HALF-LINEFEED ( for SUBSCRIPTING ) <ESC> CTRL-F 
NEGATIVE HALF-LINEFEED ( for SUPERSCRIPTING ) <ESC> CTRL-N 

The first three attribute control sequences operate in the manner of 
'toggles 1 , ie. if, for example, the printer is outputting in black, 
then the sequence <ESC> CTRL-R would switch it to red, and a further 
<ESC> CTRL-R would switch it back to black again. 

The receipt of a formfeed request , whether internally generated , or 
received as part of the text being printed, cancels out any current 
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superscripting or subscripting, ie. the top line of a new page will 
always start in the same place relative to the top of the paper. 

When preparing an original text file, the method for embedding the 
control code sequences will depend on exactly what software utility 
is being used at that time, however, as an example, we will 
illustrate the use of the standard RIO TEXT EDITOR. 

As this editor makes a special use of the code generated by 

depressing the 'ESCAPE 1 key on the console keyboard, the following 

example illustrates perhaps the most involved way of incorporating 
attribute control sequences into the text. 

The editor can be told to pass the code from the ESCAPE key into its 
output file by preceding it with the key labeled •V. This prevents 
the editor from interpreting the code from ESCAPE for its special 
function. 

Now, let's see exactly what keystroke sequences would have to be used 
in order to print the following line of text:- 

This illustrates BOLD printing. 

Using the terminology that <ESC> means the ESCAPE key, CTRL-B means 
pressing the 'B ! key whilst holding down the CONTROL-SHIFT key, the 
operator would use the following key sequence :- 

This illustrates\<ESOCTRL-B B0LD\<ESOCTRL-B printing. 

Notice that that there must not be any character between the <ESC> 
and the following attribute control code. 

Character attributes can be individually controlled. The inclusion 

of an attribute control sequence within the text is really 

interpreted as an instruction to make use of the currently set 
attribute(s) until redefined. 
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3 THE DRIVER FROM A TECHNICAL USER*S VIEWPOINT 

3.1 THE INTERFACE HARDWARE 

The printer is interfaced to the host system by the use of one of the 
four serial channels provided by an SIB (Serial Interface Board). 

There is one other major software utility which currently employs an 
SIB channel, ie. the Asynchronous Communications Package. 

The printer driver and the communications package are totally 
compatible with each other, and can successfully co-operate within a 
system. 

This driver assumes the use of channel 2 of the SIB, which is 
installed in an MCZ-1/nn style Zilog system without modification. 
Channels 2 and 3 are pre-wired in all systems currently shipped. The 
comms package uses channel 3. 

SIB modules have a great many link areas enabling the characteristics 
of each channel to be tailored to precisely suit the user's needs. 
The following link definitions are specific to channel 2, and the 
printer driver when operating with either a NEC Spinwriter model 
5510/5520, or a DIABLO model 1610/1620. 

Clock distribution :- 

J3-6 to J3-12 

J2-3 to J2-15 
J2-3 to J2-16 



Connections between USART-2 and the printer :- 

J7-1 to J7-13 
J7-2 to J7-14 
J7-3 to J7-11 
J7-4 to J7-12 
J7-5 to J7-10 
J7-6 to J7-9 



The above links configure channel 2 of the SIB to communicate with a 
'terminal 1 , and interface the following signals at the 25 way socket 
with which the printer is to be connected. In most MCZ-1/nn systems 
this is labeled f J102'. 



6-12 



Spinwriter/Diablo driver Revision 2 ♦ 1 

The actual interface signals are as follows :- 

J 102-7 Ground 

J 102-8 'spare' 

J 102-5 Clear To Send -> To printer 

J 102-6 Data Set Ready -> To printer 

J 102-20 Data Terminal Ready <- From printer 

J 102-4 Request To Send <- From printer 

J 102-3 Received data <- From printer 

J 102-2 Transmitted data -> To printer 



The printer driver assumes that a rate of 1200 bauds will be used, 
and switches in the printer must be appropriately set. As those 
settings depend upon the exact printer model number, it is 
impracticable to give them here. 



All other links on the SIB are either to be left as when delivered, 
or set as required for defining the characteristics of the channels 
which are not used by the printer driver 
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3.2 THE DRIVER SOFTWARE - GENERAL 

This driver operates by placing character codes into a line buffer in 
locations which correspond to columns of the output line. ie. the 
content of the line buffer is columnated. 

Before being written into, the line buffer is cleared to contain 
space codes in bits -> 6. Bit 7 is handled independently, and, 
when set, defines the location of a tab-stop. Each time the line 
buffer is cleared, the setting of bit 7 is left unaffected in each 
location . 

The tab bits are defined after a call is made to determine the 
current tab locations in use by the system console driver. This is 
done each time an initialisation request is received by the printer 
driver. 

A second columnated buffer is used in addition to the line buffer. 
This contains character attributes and effectively extends each 
character code to include bits which independently define whether the 
character is to be printed in red, bold, underlined, or as a 
superscript or subscript. As currently implemented, there are three 
spare attribute bits, which could easily be allocated for specific 
extensions to the driver's capabilities. 

The attribute buffer is loaded according to the attribute control 
sequences embedded in the input text. These are used to directly 
control the value of the variable NEXTJITTRIBUTE , which is copied 
into the attribute buffer when a character is placed into the line 
buffer . 

After the line and attribute buffers have been loaded, the driver 
decides whether the current printhead position is nearer to the left 
or right end of the line about to be printed, and is therefore able 
to perform an absolute tab to the nearer end, and output the line in 
the appropriate direction. 

Notice that the driver never issues a carriage-return code to the 
printer. It always sends absolute tabs and linefeeds. This is due 
to the danger of accidently locking the "Auto Linefeed" switch of 
some printers, which is sometimes located near to frequently used 
controls. Its use would destroy carefully defined formats. 

It is expected that any programmer who wishes to understand, or 
modify, the driver will be able to do so easily after reading the 
module listings. Therefore a blow-by-blow descriptions of the 
operation is considered unnecessary. 
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3.3 THE MODULES 

The driver software consists of a number of modules, each being 
written in the language chosen to be most appropriate for the 
function it performs. 

The modules perform the following general functions :- 



MODULE FUNCTION 

PRINTER. DRIVER. ( PLZSYS ) 

Receives the RIO request vector from RIO . 10 . INTERFACE 
and interprets the request code. Makes a call back to 
RIO in order to determine the TABSTOP locations within 
the standard RIO console driver so as to be able to use 
the same locations itself. 

PRINTER. DRIVER. 1 ( PLZSYS ) 

Contains the procedures for building the LINE and 
ATTRIBUTE buffers. 

PRINTER. DRIVER. 2 ( PLZSYS ) 

Contains the procedures for optimising print direction 
and removing data from the LINE and ATTRIBUTE buffers 
during actual printing. 

DIABLO and SPINWRITER ( PLZSYS ) 

These modules contain printer-dependent procedures for 
selecting print direction, absolute tabbing, selecting 
ribbon colour, requesting positive or negative half 
linefeeds for subscripting and superscripting , and 
management of ETX/ACK protocol for maintaining control 
of the buffer in the printer itself. 

This is the only module of the driver which is not 
common to both the Spinwriter and the Diablo. 
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RIO. 10. INTERFACE ( ASSEMBLER ) 

This very simple module merely converts the IY register 
content received from RIO as the request-vector-pointer 
into a PLZSYS procedure parameter. It then passes 
control to the main procedure in PRINTER. DRIVER. 

Return to RIO is through this module so that IY can be 
restored. 



SIB ( ASSEMBLER ) 



This module contains the routines to set up the basic 
I/O interface to the printer. All routines may be 
called direct from PLZSYS code. 

All character level I/O is performed by this module. 



CALL. SYSTEM ( ASSEMBLER ) 

This module receives a pointer as a parameter from a 
PLZSYS program, and passes it as an RIO I/O request 
vector pointer to RIO. In this driver it is used when 
requesting the status of $C0N to determine if an abort 
has been requested , for getting tab locations from $C0N , 
also for issuing messages to, and obtaining operator 
responses from $C0N. 



PLZ. INTERFACE. MACROS ( ASSEMBLER ) 
For convenience only. 
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4 CONCLUSION 

Hopefully this note will have given the reader a few ideas about the 
use of PLZSYS in association with Assembly Language for I/O driver 
writing. The author cannot realistically recommend its use if memory 
space is at a premium, but certainly does recommend it wholeheartedly 
if an objective is to produce intelligible, easily adaptable code 
quickly. The entire driver described herein took less than 30 
man-hours to design, implement and test. 

The source code files for all modules are available from Zilog's 
franchised distributors as part of the software library. 

Any users 1 improvements to this driver would be warmly welcomed if 
contributed to the Software Library. 
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2.02 
PRINTER J)RIVER_0 



MODULE 



Extended 3/3/79 to allow for subscripting and superscripting ! 
Also for operator controlled page-waits and auto formfeed ! 



TYPE 



RI0__REQUEST__VECT0R 



RECORD [ 



CONSTANT 



INITIALISE 

ASSIGN 

OPEN 

CLOSE 

WRITEJ3INARY 

WRITE_LINE 

READ_LINE 

READJSTATUS 

WRITEJSTATUS 

DEACTIVATE 

INVALIDJOPERATION_REQUEST 

PR0GRAMME_AB0RT 

G00DJETURN 

CONIN 

CONOUT 

ASCIIJSPACE 

ASCII_CR 

ASCIIJLF 

ASCII_FF 

ASCIIJ3ELL 

BLACK 

TRUE 

FALSE 

INTERRUPT __REQUEST_MASK 

TAB BIT 



EXTERNAL 



REQUEST_BLACK 

GETJCODE 

SETCH2 

ABS0LUTE_TAB 

FORMFEED 



LUN 


BYTE 


REQ 


BYTE 


DTA 


"BYTE 


DTL 


WORD 


CRA 


WORD 


ERA 


WORD 


CCOD 


BYTE 


SPYJlDD 


WORD 





J02 

#04 

%oe 

JOE 

#10 

#0C 

#40 

#42 

#44 

*C1 

#49 

#80 

1 

2 
t t 

'JR 1 

•#P f 

#07 

#01 

1 


#FE 
#80 



PROCEDURE 
PROCEDURE 
PROCEDURE 
PROCEDURE ( BYTE ) 
PROCEDURE 
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53 
54 
55 
56 
57 
58 
59 
60 
61 
62 

63 
64 
65 
66 
67 
68 
69 
70 
71 
72 
73 
74 
75 
76 
77 
78 
79 
80 
81 
82 
83 
84 
85 
86 
87 
88 
89 
90 
91 
92 
93 
94 
95 
96 
97 
98 
99 
100 
101 
102 
103 
104 
105 



o driver 


Revision 2 . 1 


PRINT_LINE_BUFFER 


PROCEDURE 


CALRIO 


PROCEDURE ( "BYTE ) 




RETURNS ( BYTE ) 


CLEAR_LINE__BUFFER 


PROCEDURE 


LINE_CONTAINSJPRINTABLE_CHAR 


BYTE 


CODE 


BYTE 


ATTRIBUTE__SEQUENCE_FLAG 


BYTE 


NEXT_ATTRIBUTE 


BYTE 


LINEJFINISHED_FLAG 


BYTE 


EOF_FLAG 


BYTE 


BYTES_TAKEN_FROM_SOURCE 


WORD 


BYTE_COUNT 


BYTE 


CONSOLE JSTATUSJUFFER 


ARRAY [ 5 BYTE ] 


LINEJ3UFFER 


ARRAY [ 163 BYTE ] 


LINEJBUFFER_PTR 


"BYTE 



INTERNAL 



INPUTjCHAR 

dat encode 

NEWJSHEETJISG 

BELLJSTRING 

CUTJSHT_QUES 

AUTO__FM__FEEDJ3UES 

NL ARRAY 



GENERAL__RIO_CALL_VECTOR 

GLOBAL 

REQUEST__CODE 

SOURCE_PTR 

DATA_LENGTH 

ABORT_FLAG 

AUTOJFFJFLAG 

PAGE WAIT FLAG 



CALLJIO 



PROCEDURE 



UNIT 
REQUEST 
DATA_ADDRESS 
DATA_LENGTH 



LOCAL RETURN_CODE BYTE 

ENTRY 

GENERAL_RIO_CALL_VECTOR . LUN 
GENERAL__RIO_CALL_VECTOR . REQ 
GENERAL__RIO_CALL_VECTOR . DTA 
GENERAL _RIO_CALL_VECTOR . DTL 



BYTE 



ARRAY [* BYTE ] 

ARRAY [* BYTE ] 

ARRAY [1 BYTE ] 

ARRAY [* BYTE ] 

ARRAY [* BYTE ] 

ARRAY [« BYTE ] 



f jRPr inter Driver rev. 
1 Load new sheet , hit a 

[ ASCII_BELL ] 
f JRCut sheets ? ' 
♦Auto formfeed ? f 
•JtR 1 

RIOJREQUESTJTECTOR 



2.1*R» 
key : • 



BYTE 

"BYTE 

WORD 

BYTE 

BYTE 

BYTE 



BYTE 
BYTE 
"BYTE 
WORD ) 



= UNIT 
= REQUEST 
= DATA_ADDRESS 
= DATA LENGTH 
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106 GENERAL_RIO__CALL_VECTOR.CRA := 

107 GENERAL _RI0_CALL_VECT0R. ERA := 

108 GENERAL JRIO_CALL.VECTOR.CCOD := 

109 GENERAL_RIO_CALL_VECTOR.SPV__ADD := 
110 

111 RETURN_CODE := CALRIO ( #GENERAL _RI0__CALL_VECT0R . LUN ) 

112 

113 IF RETURN_CODE <> G00D_RETURN 

114 THEN 

115 ABORT_FLAG := TRUE 

116 FI 
117 

118 END CALLJIO 

119 

120 

121 MAYBE_ABORT PROCEDURE 

122 

123 ENTRY 

124 

125 CALLJIO ( CONIN 

126 READ_STATUS 

1 27 #CQNSOLE JST ATUS JUFFER [ ] 

128 1 ) 
129 

130 IF ( CONSOLE_JSTATUS_BUFFER[0] AND $20 ) = 

131 THEN 

132 ABORT__FLAG := TRUE 

133 FI 
134 

135 END MAYBE_ABORT 

136 

137 

138 NEWLINE PROCEDURE 

139 

140 ENTRY 

141 CALL_RI0 ( CONOUT 

142 WRITE JBINARY 

143 #NL_ARRAY[0] 

144 SIZEOF NL_ARRAY ) 
145 

146 END NEWLINE 

147 

148 

149 GET_CHAR PROCEDURE 

150 

151 ENTRY 

152 CALLJIO ( CONIN 

153 READJLINE 

154 #INPUTJCHAR 

155 1 ) 
156 

157 IF INPUT_CHAR <> 'JR' THEN NEWLINE FI 

158 

Appendix 6-20 PRINTER. DRIVER. 



Spinwriter/Diablo driver 



Revision 2.1 



159 


END 


GET_CHAR 


160 






161 






162 


PAGE_WAIT PROCEDURE 


163 






164 




ENTRY 


165 




CALLJIO ( CONOUT 


166 




WRITE JINARY 


167 




#NEWJSHEET_MSG[0] 


168 




SIZEOF NEW_JSHEET_MSG + SIZEOF BELL_STRING ) 


169 




GETJCHAR 


170 




IF INPUT_CHAR 


171 




CASE , C» f c ! 


172 




THEN 


173 




PAGE_WAIT_FLAG := FALSE 


174 




NEWLINE 


175 




FI 


176 






177 


END 


PAGEJWAIT 


178 






179 






180 


GET. 


.FLAGS PROCEDURE 


181 






182 




ENTRY 


183 




CALL_RI0 ( CONOUT 


184 




WRITE_BINARY 


185 




#date_code[0] 


186 




SIZEOF date_code ) 


187 






188 




CALL_RI0 ( CONOUT 


189 




WRITE JINARY 


190 




#CUT_SHT_QUES[0] 


191 




SIZEOF CUT_SHT_QUES ) 


192 






193 




GET_CHAR 


194 




PAGE_WAIT_FLAG := FALSE 


195 




IF INPUT_CHAR 


196 




CASE »Y' 'y' 


197 




THEN PAGE WAIT FLAG := TRUE 


198 




FI 


199 




CALL_RI0 ( CONOUT 


200 




WRITE JBINARY 


201 




#AUTO_FM_FEED_QUES [ ] 


202 




SIZEOF AUTO_FM_FEED_QUES ) 


203 






204 




GET_CHAR 


205 




AUTO_FFJFLAG := FALSE 


206 




IF INPUT_CHAR 


207 




CASE 'Y 1 'y 1 


208 




THEN AUTO_JT_FLAG := TRUE 


209 




FI 


210 




NEWLINE 


211 




NEWLINE 
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212 

213 END GET_FLAGS 

214 

215 

216 GETJTABJLOCATIONS PROCEDURE 

217 

218 LOCAL COUNTER BYTE 

219 

220 ENTRY 

221 CALLJIO ( CONIN 

222 READJSTATUS 

223 #CONSOLE__STATUSJBUFFER [0 ] 

224 139 ) 
225 

226 COUNTER := 

227 LINEJBUFFER_PTR := # LINE_BUFFER [0] 

228 DO 

229 IF COUNTER = 163 THEN EXIT FI 

230 IF COUNTER < 134 

231 THEN 

232 IF LINE_BUFFER_PTR" <> 

233 THEN 

234 LINEJUFFERJPTR* := TABJBIT 

235 ELSE 

236 LINE_BUFFERJ?TR* := 

237 FI 
238 

239 ELSE 

240 LINEJ3UFFER_PTR* := TABJBIT 

241 FI 
242 

243 LINE_BUFFERJPTR := INC LINEJBUFFER_PTR 

244 COUNTER += 1 

245 OD 
246 

247 CLEAR__LINE_BUFFER 

248 

249 END GET_TAB_LOCATIONS 

250 

251 

252 EJECT_PAGE PROCEDURE 

253 

254 ENTRY 

255 IF PAGE_WAIT_FLAG = TRUE 

256 THEN 

257 PAGE_WAIT_FLAG := FALSE 

258 FORMFEED 

259 PAGE_WAIT_FLAG := TRUE 

260 ELSE 

261 FORMFEED 

262 FI 
263 

264 END EJECT PAGE 
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265 

266 

267 PLZDVR PROCEDURE ( VECTOR_PTR ~RI0__REQUEST_VECT0R ) 

268 

269 ENTRY 

270 REQUEST__C0DE := VECTOR_PTR~ .REQ AND INTERRUPT JEQUESTJMASK 

271 S0URCE_PTR := VECTOR_PTR~ . DTA 

272 DATA_LENGTH := VECTOR_PTR" .DTL 
273 

274 VECTORJPTR^.CCOD := GOODJRETURN 

275 VECTOR_PTR~.DTL := 
276 

277 BYTES_TAKEN_FROM_SOURCE := 

278 EOF_FLAG := FALSE 

279 ABORT_FLAG := FALSE 
280 

281 IF REQUEST_CODE 

282 

283 CASE INITIALISE 

284 THEN 

285 SETCH2 

286 BYTE__COUNT := 

287 ABSOLUTE_TAB (1) 

288 EJECT_PAGE 

289 ATTRIBUTE_SEQUENCE_FLAG := FALSE 

290 NEXT_ATTRIBUTE := BLACK 

291 REQUEST JBLACK 

292 GET_TAB_LOCATIONS 

293 GET_FLAGS 
294 

295 RETURN 

296 

297 CASE ASSIGN 

298 THEN 

299 RETURN 
300 

301 CASE OPEN 

302 THEN 

303 GETJTAB_L0CATI0NS 

304 RETURN 
305 

306 CASE CLOSE, DEACTIVATE 

307 THEN 

308 ABSOLUTEJTAB (1) 

309 EJECT_PAGE 

310 RETURN 
311 

312 CASE WRITE ^BINARY 

313 THEN 

314 DO 

315 IF DATA_LENGTH = BYTESJTAKEN_FR0M_S0URCE 

316 THEN 

317 EXIT 
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318 FI 

319 GET__CODE 

320 IF E0F_FLAG = TRUE 

321 THEN 

322 EXIT 

323 FI 

324 IF ABORTJFLAG = TRUE 

325 THEN 

326 VECTOR._PTR~.CCOD := PROGRAMME__ABORT 

327 EJECT__PAGE 

328 EXIT 

329 FI 

330 OD 
331 

332 VECTOR__PTR'\DTL := BYTES__TAKEN__FROM__SOURCE 

333 RETURN 
334 

335 CASE WRITE JLINE 

336 THEN 

337 LINE_CONTAINS_.PRINTABLE__.CHAR := FALSE 

338 DO 

339 IF DATA__LENGTH = BYTES__TAKEN__FROM__SOURCE 

340 THEN 

341 PRINT_LINE_BUFFER 

342 EXIT 

343 FI 
344 

345 GET__C0DE 

346 IF CODE = ASCII__CR THEN EXIT FI 

347 IF ABORT__FLAG = TRUE 

348 THEN 

349 VECTOR^PTR'.CCOD := PROGRAMME__ABORT 

350 EJECT_PAGE 

351 EXIT 

352 FI 

353 OD 
354 

355 VECTOR_PTR~.DTL := BYTES_JAKEN__FROM__SOURCE 

356 

357 RETURN 

358 

359 ELSE 

360 

361 VECTOR__PTR".CCOD := INVALIDJDPERATIONJREQUEST 

362 

363 FI 

364 

365 END PLZDVR 
366 

367 END PRINTER_DRIVER_0 
END OF ZCODE GENERATION 

ERROR (S) WARNING (S) 
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PLZSYS 


2.02 


1 


PRINTER_DRIVER_1 MODULE 


2 




3 


! Extended 3/3/79 to allow for 


4 




5 




6 


CONSTANT 


7 




8 


TRUE 


9 


FALSE 


10 




11 


ASCIIJSPACE 


12 


ASCIIJTAB 


13 


ASCIIJ3S 


14 


ASCII_ESC 


15 


ASCII_FF 


16 


ASCII_CR 


17 


ASCIIJLF 


18 


ASCII_C0NTR0L_R 


19 


ASCII_CONTROL_B 


20 


ASCII_C0NTR0L_U 


21 


ASCII_C0NTR0L_N 


22 


ASCII_C0NTR0L_F 


23 




24 


BLACK 


25 


RED 


26 


BOLD 


27 


NOT_BOLD 


28 


UNDERLINE 


29 


NOTJJNDERLINE 


30 


SUPERSCRIPT 


31 


N0TJ3UPERSCRIPT 


32 


SUBSCRIPT 


33 


NOT_SUBSCRIPT 


34 




35 


TAB_MASK 


36 


PARITY_MASK 


37 




38 


EXTERNAL 


39 




40 


PRINTERJHIDTH 


41 


PRINTLINE JBUFFER 


42 


FORMFEED 


43 


LINEFEED 


44 


MAYBE_ABORT 


45 




46 


SOURCE JPTR 


47 




48 




49 


GLOBAL 


50 




51 


CODE 


52 


BYTES_TAKEN_FROM_SOURCE 
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subscripting and superscripting 



:= 1 






:= 






.. t t 






:= $09 






:= $08 






:= $1B 






:= $0C 






:= f W 






:= ^L 1 






:= $12 


i 


COLOUR CHANGE ! 


:= $02 


! 


BOLD ! 


:= $15 


! 


UNDERLINE ! 


:= $0E 


! 


SUPERSCRIPT ! 


:= $06 


! 


SUBSCRIPT ! 


:= $01 






:= NOT 


BLACK 


:= $02 






:= NOT 


BOLD 


:= $04 






:= NOT 


UNDERLINE 


:= $08 






:= NOT 


SUPERSCRIPT 


:= $10 






:= NOT 


SUBSCRIPT 


:= $80 






:= $7F 






BYTE 






PROCEDURE 




PROCEDURE 




PROCEDURE 




PROCEDURE 





'BYTE 



BYTE 
WORD 
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53 
54 
55 
56 
57 
58 
59 
60 
61 
62 
63 
64 
65 
66 
67 
68 
69 
70 
71 
72 
73 
74 
75 
76 
77 
78 
79 
80 
81 
82 
83 
84 
85 
86 
87 
88 
89 
90 
91 
92 
93 
94 
95 
96 
97 
98 
99 
100 
101 
102 
103 
104 
105 



CONSOLEJSTATUSJBUFFER 

LINE_BUFFER 

ATTRIBUTEJBUFFER 

C0LUMN_N0 

LINEJ?ONTAINSJ>RINTABLE_CHAR 

CHARS_JN__LINE_BUFFER 

ATTRIBUTE 

NEXT_ATTRIBUTE 

ATTRIBUTE_BUFFER_j ) TR 

LEFTMOST_PRINTABLE_COLUMN 

RIGHTMOST_PRINTABLE__COLUMN 

LINEJBUFFER__PTR 

ATTRIBUTE_SEQUENCE__FLAG 

EOFJFLAG 

LINE_FINISHED_FLAG 



ARRAY [ 5 BYTE ] 

ARRAY [ 163 BYTE ] 

ARRAY [ 163 BYTE ] 

BYTE 

BYTE 

BYTE 

BYTE 

BYTE 

"BYTE 

BYTE 

BYTE 

"BYTE 

BYTE 

BYTE 

BYTE 



CLEARJ.INEJBUFFER 



PROCEDURE 



ENTRY 

LINEJBUFFERJTR : = #LINEJBUFFER [0] 
COLUMNJJO := 1 

LINE__CONTAINSJPRINTABLE_CHAR := FALSE 
LEFTMOST_PRINTABLE_COLUMN := 1 
RIGHTMOST PRINTABLE COLUMN := 1 



DO 



IF COLUMNJJO > PRINTER_WIDTH 
THEN 

C0LUMN_N0 := 1 

LINE__BUFFER_PTR := #LINE_BUFFER [0] 

ATTRIBUTE_BUFFER_PTR := # ATTRIBUTEJBUFFER [0] 

RETURN 
FI 



LINEJUFFERJPTR" 

LINEJBUFFER_PTR 
COLUMNJJO += 1 



:= ( LINE_BUFFERJPTR~ AND TABJ4ASK ) 

OR ASCIIJSPACE 
= INC LINEJBUFFERJ>TR 



OD 



END CLEAR JLINE_BUFFER 



PUT_CODE__INTOJ J INE_BUFFER 



PROCEDURE 



ENTRY 

LINE_BUFFERJ>TR~ := ( LINE_BUFFER_PTR~ AND TAB_MASK ) 

OR CODE 
ATTRIBUTEJBUFFER JPTR" := NEXT_ATTRIBUTE 

IF LINE_C0NTAINS_PRINTABLE_CHAR = FALSE 
THEN 

LEFTMOSTJPRINTABLE__COLUMN := COLUMN_NO 
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106 LINE_C0NTAINS_J > RINTABLE_CHAR := TRUE 

107 FI 
108 

109 RIGHTM0ST_PRINTABLE_C0LUMN := C0LUMN__N0 

110 COLUMN JJO += 1 

111 LINEJUFFERJPTR := INC LINEJBUFFER_PTR 

112 ATTRIBUTE J3UFFER_PTR := INC ATTRIBUTE JBUFFER_PTR 

113 

114 END PUT_C0DE_INT0_LINE_BUFFER 

115 

116 

1 1 7 GOT JTAB PROCEDURE 

118 

119 ENTRY 

120 DO 

121 LINE_BUFFER_PTR := INC LINEJBUFFER_PTR 

122 ATTRIBUTE__BUFFER_J>TR* := NEXTJITTRIBUTE 

123 ATTRIBUTE_BUFFER_PTR := INC ATTRIBUTE JBUFFERJPTR 

124 COLUMNJJO += 1 

125 IF ( LINEJBUFFERJPTR* AND TAB_MASK ) <> 

126 THEN 

127 RETURN 

128 FI 

129 OD 
130 

131 END GOT_TAB 

132 

133 

134 FETCHJITTRIBUTfi PROCEDURE 

135 

136 ENTRY 

137 ATTRIBUTEJSEQUENCEJFLAG := FALSE 
138 

139 IF CODE 

140 

141 CASE ASCII_C0NTR0L_R 

142 THEN 

143 IF NEXT_ATTRIBUTE AND BLACK <> 

144 THEN 

145 NEXTJITTRIBUTE := NEXTJITTRIBUTE AND RED 

146 ELSE 

147 NEXTJITTRIBUTE := NEXTJITTRIBUTE OR BLACK 

148 FI 
149 

150 CASE ASCII_C0NTR0LJB 

151 THEN 

152 IF NEXTJITTRIBUTE AND BOLD <> 

153 THEN 

154 NEXT_ATTRIBUTE := NEXTJITTRIBUTE AND N0T_B0LD 

155 ELSE 

156 NEXTJITTRIBUTE := NEXTJITTRIBUTE OR BOLD 

157 FI 
158 
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159 CASE ASCII_C0NTR0L_U 

160 THEN 

161 IF NEXT^ATTRIBUTE AND UNDERLINE <> 

162 THEN 

163 NEXT_ATTRIBUTE := NEXT_ATTRIBUTE 

164 AND NOTJJNDERLINE 

165 ELSE 

166 NEXT_ATTRIBUTE := NEXT__ATTRIBUTE 

167 Ofl UNDERLINE 

168 FI 
169 

170 CASE ASCII_C0NTR0L_N 

171 THEN 

172 IF NEXT_ATTRIBUTE AND SUBSCRIPT <>0 

173 THEN 

174 NEXTJOTRIBUTE := NEXT_ATTRIBUTE 

175 AND NOTJSUBSCRIPT 

176 ELSE 

177 NEXT__ATTRIBUTE := NEXT.ATTRIBUTE 

178 OR SUPERSCRIPT 

179 FI 
180 

181 CASE ASCII__C0NTR0L_F 

182 THEN 

183 IF NEXT_ATTRIBUTE AND SUPERSCRIPT <> 

184 THEN 

185 NEXTJITTRIBUTE := NEXT__ATTRIBUTE 

186 AND NOTJSUPERSCRIPT 

187 ELSE 

188 NEXT_ATTRIBUTE := NEXT__ATTRIBUTE 

189 OR SUBSCRIPT 

190 FI 
191 

192 FI 

193 

194 END FETCH_ATTRIBUTE 

195 

196 

197 GET__C0DE PROCEDURE 

198 

199 ENTRY 

200 CODE := SOURCE_J>TR~ 
201 

202 IF CODE = JFF 

203 THEN 

204 E0F_FLAG := TRUE 

205 RETURN 

206 FI 
207 

208 CODE := CODE AND PARITY__MASK 

209 SOURCEJPTR := INC SOURCE__PTR 

210 BYTES_TAKEN_FR0M_S0URCE += 1 

211 IF ATTRIBUTE_JSEQUENCE_FLAG = TRUE 
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212 THEN 

2 1 3 FETCHJVTTRIBUTE 

214 RETURN 

215 FI 

216 IF CODE > ASCIIJSPACE 

217 THEN 

2 1 8 PUT_CODE_INTO_LINE_BUFFER 

219 RETURN 

220 FI 

221 IF CODE 
222 

223 CASE ASCIIJSPACE 

224 THEN 

225 LINE_BUFFER_PTR := INC LINEJBUFFER_PTR 

226 ATTRIBUTE JBUFFERJPTR* := NEXT_ATTRIBUTE 

227 ATTRIBUTE_BUFFER_PTR := INC ATTRIBUTE JBUFFER_PTR 

228 C0LUMN_N0 += 1 
229 

230 CASE ASCII_CR 

231 THEN 

232 PRINT JLINEJUFFER 

233 LINEFEED 

234 MAYBE_ABORT 
235 

236 CASE ASCII_FF 

237 THEN 

238 PRINT JLINEJ3UFFER 

239 FORMFEED 

240 MAYBE_ABORT 
241 

242 CASE ASCII J.F 

243 THEN 

244 PRINT_LINE_BUFFER 

245 LINEFEED 

246 MAYBE_ABORT 
247 

248 CASE ASCIIJTAB 

249 THEN 

250 GOTJTAB 
251 

252 CASE ASCIIJESC 

253 THEN 

254 ATTRIBUTE_SEQUENCE_FLAG := TRUE 
255 

256 FI 

257 

258 END GET_CODE 
259 
260 

261 END PRINTER J)RIVER_1 
END OF ZCODE GENERATION 

ERROR (S) WARNING (S) 
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PLZSYS 

1 

2 

3 

4 

5 

6 

7 

8 

9 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 

23 
24 
25 
26 
27 
28 
29 
30 
31 
32 
33 
34 
35 
36 
37 
38 
39 
40 
41 
42 
43 
44 
45 
46 
47 
48 
49 
50 
51 
52 



2.02 
PRINTER JDRIVER_2 

CONSTANT 



MODULE 



ASCIIJSPACE 

PARITYJMASK 

FORWARD 

BACKWARD 

TRUE 
FALSE 

WRITEJLINE 

EXTERNAL 

LEFTMOST_PRINTABLE_COLUMN 

RIGHTMOST_PRINTABLE_COLUMN 

PRESENT_COLUMN 

DIRECTION 

CHARS_IN_LINE__BUFFER 

LINEJBUFFER_PTR 

ATTRIBUTE JBUFFERJPTR 

ATTRIBUTE 

REQUESTJ30DE 

LINE CONTAINS_PRINTABLE_CHAR 



LINEJBUFFER 
ATTRIBUTE JB&FFER 



ABSOLUTE_TAB 

SEND 

PRINT 



REQUEST_FORWARD 
REQUESTJACKWARD 
WAIT_FOR_ACK 
CLEAR JLINEJBUFFER 



INTERNAL 



CHAR 

COLUMN_NO 
NEXTJCOLUMMLNO 
SPACE__COUNT 
SPACE_SKIP FLAG 



:= %7F 

:= 1 

:= 

:= 1 

:= 

:= J10 



BYTE 

BYTE 

BYTE 

BYTE 

BYTE 

"BYTE 

"BYTE 

BYTE 

BYTE 

BYTE 



ARRAY [ 163 BYTE ] 
ARRAY [ 163 BYTE ] 



PROCEDURE ( BYTE ) 
PROCEDURE ( BYTE ) 
PROCEDURE ( BYTE BYTE ) 

! CHAR, ATTRIBUTE ! 

PROCEDURE 
PROCEDURE 
PROCEDURE 
PROCEDURE 



BYTE 
BYTE 
BYTE 
BYTE 
BYTE 
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53 

54 SETJJPJDIRECTION PROCEDURE 

55 

56 ENTRY 

57 

58 IF LEFTMOST_PRINTABLE_COLUMN > PRESENT_COLUMN 

59 THEN 

60 ABS0LUTE_TAB ( LEFTMOST_PRINTABLE_COLUMN ) 

61 REQUEST_FORWARD 

62 RETURN 

63 FI 
64 

65 IF PRESENT_COLUMN > RIGHTMOST_PRINTABLE__COLUMN 

66 THEN 

67 ABSOLUTE_TAB ( RIGHTMOST_PRINTABLE_COLUMN ) 

68 REQUESTJBACKWARD 

69 RETURN 

70 FI 
71 

72 IF (RIGHTMOST_PRINTABLE_COLUMN - PRESENT_COLUMN ) 

73 > ( PRESENT_COLUMN - LEFTMOST_PRINTABLE_COLUMN ) 

74 THEN 

75 ABSOLUTEJTAB ( LEFTMOST_PRINTABLE__COLUMN ) 

76 REQUEST_FORWARD 

77 RETURN 

78 FI 
79 

80 ABSOLUTEJTAB ( RIGHTMOSTJ>RINTABLE_COLUMN ) 

81 REQUESTJBACKWARD 
82 

83 END SET_UP_DIRECTION 

84 

85 

86 GLOBAL 

87 

88 

89 PRINT_LINE_BUFFER PROCEDURE 

90 

91 ENTRY 

92 

93 IF LINE_CONTAINS_PRINTABLE_CHAR = FALSE 

94 THEN 

95 CLEAR_LINE_BUFFER RETURN 

96 ELSE 

97 CHARS_IN_LINE__BUFFER := RIGHTMOST__PRINTABLE_COLUMN 

98 - LEFTMOST_PRINTABLE_COLUMN + 1 

99 FI 
100 

1 1 SET_UP_DIRECTION 

102 LINE_BUFFER_PTR := #LINE_BUFFER [ PRESENT_COLUMN-1 ] 

103 ATTRIBUTE_BUFFER_PTR := #ATTRIBUTE_BUFFER [ PRESENT_COLUMN-1 ] 

104 NEXT_COLUMN_NO := PRESENT_COLUMN 

105 SPACE_SKIP_FLAG := FALSE 
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106 SPACE_C0UNT := 

107 DO 
108 

109 IF CHARS_IN_LINE__BUFFER = 

110 THEN 

1 1 1 CLEAR__LINE_BUFFER 

112 RETURN 

113 FI 
114 

115 

116 C0LUMN_N0 := NEXT_C0LUMN_N0 

117 CHAR := LINE_BUFFER_PTR* AND PARITY__MASK 

118 ATTRIBUTE := ATTRIBUTEJBUFFER_PTR" 

119 IF DIRECTION = BACKWARD 

120 THEN 

121 LINEJBUFFER_J>TR := DEC LINE_BUFFERJ>TR 

122 ATTRIBUTE J3UFFERJPTR := DEC ATTRIBUTE__BUFFER__PTR 

123 NEXT_COLUMNJJO -= 1 

124 ELSE 

125 LINEJBUFFER_PTR := INC LINEJBUFFER_PTR , 

126 ATTRIBUTE JUFFER_PTR := INC ATTRIBUTE JBUFFERJPTR 

127 NEXT_COLUMN_NO += 1 

128 FI 
129 

130 CHARSJNJLINEJUFFER -= 1 

131 

132 IF CHAR = ASCII JSPACE 

133 THEN 

134 IF SPACEJSKIPJFLAG = FALSE 

135 THEN 

136 SPACE_SKIP_FLAG := TRUE 

137 SPACE_COUNT := 1 

138 REPEAT 

139 FI 
140 

141 SPACE_COUNT += 1 

142 REPEAT 

143 FI 
144 

145 IF SPACEJSKIP_FLAG = TRUE 

146 THEN 

147 SPACE_SKIP_FLAG := FALSE 

148 IF SPACE_COUNT >= 3 

149 THEN 

150 ABSOLUTEJTAB ( COLUMNJNO ) 

151 ELSE 

152 DO 

153 IF SPACE_COUNT = THEN EXIT FI 

154 PRINT ( ASCIIJSPACE ATTRIBUTE ) 
155 

156 SPACE_COUNT -= 1 

157 OD 

158 FI 
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159 
160 
161 
162 
163 
164 
165 
166 
167 
168 
169 
END 




FI 



PRINT ( CHAR ATTRIBUTE ) 



0D 



END PRINT LINE BUFFER 



END PRINTER_DRIVER_2 
OF ZCODE GENERATION 
ERROR (S) WARNING (S) 
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PLZSYS 


2.02 








1 
2 
3 


SPINWRITER MODULE 






! Extended 3/3/79 to allow for 


subscripting and superscr: 


4 
5 


! Also for page-waits and 


controllable auto-formfeed ! 


6 
7 
8 


CONSTANT 






9 
10 


PRINTER_BUFFER_SIZE 




:= 256 


11 


PITCH 






= 12 


12 


SS 






= 120/PITCH 


13 








14 


ASCIIJETX 






= $03 


15 


ASCII_ACK 






= %06 


16 


ASCII__ESC 






= *1B 


17 


ASCII_FF 






= $0C 


18 


ASCIIJS 






= $08 


19 


ASCII_UL 






= * ' 


20 


ASCIIJSPACE 






= ' ! 


21 








22 


PARITY_MASK 




:= $7F 


23 








24 


FORWARD 




:= 1 


25 


BACKWARD 




:= 


26 








27 


BLACK 






:= %01 


28 


BOLD 






= $02 


29 


UNDERLINE 






:= $04 


30 


SUPERSCRIPT 






:= $08 


31 


NOT.JSUPERSCRIPT 






:= NOT SUPERSCRIPT 


32 


SUBSCRIPT 






:= $10 


33 


NOTJSUBSCRIPT 






:= NOT SUBSCRIPT 


34 








35 


TRUE 




:= 1 


36 


FALSE 




:= 


37 








38 








39 


INTERNAL 






40 








41 


LINE_COUNT 




BYTE 


42 


COLOUR 




BYTE 


43 


HMI 




BYTE 


44 


SUBSCRIPT.FLAG 




BYTE 


45 


SUPERSCRIPTJFLAG 




BYTE 


46 








47 


LAST_SCRIPT__STATE 




BYTE 


48 








49 








50 


EXTERNAL 






51 








52 


0UTCH2 




PROCEDURE ( BYTE ) 


Append 


ix 
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53 




INCH2 PROCEDURE RE r 


54 






55 




PAGEJtfAIT PROCEDURE 


56 






57 




NEXT_ATTRIBUTE BYTE 


58 






59 




PAGE_.WAIT.JLAG BYTE 


60 




AUTO_FF_FLAG BYTE 


61 






62 






63 




GLOBAL 


64 






65 




PRINTER_WIDTH BYTE := 163 


66 




DIRECTION BYTE 


67 




PRESENT_COLUMN BYTE 


68 




AUTO_FFJLINE_COUNT BYTE := 63 


69 




BYTE_COUNT BYTE 


70 






71 






72 


SEND_ETX PROCEDURE 


73 




ENTRY 


74 




0UTCH2 ( ASCIIJSTX ) 


75 




BYTEJCOUNT := 


76 


END 


SEND_ETX 


77 






78 






79 


WAITJOR_ACK PROCEDURE 


80 




ENTRY 


81 




DO 


82 




IF ( INCH2 AND PARITY__MASK ) = ASCII_ACK 


83 




THEN 


84 




RETURN 


85 




FI 


86 




OD 


87 


END 


WAITJOR_ACK 


88 






89 






90 


SEND PROCEDURE ( CODE BYTE ) 


91 




ENTRY 


92 




IF BYTEJCOUNT > PRINTER _BUFFER_SIZE - 10 


93 




THEN 


94 




SEND_ETX 


95 




WAIT_FOR_ACK 


96 




FI 


97 




BYTE_COUNT += 1 


98 




OUTCH2 ( CODE ) 


99 






100 


END 


SEND 


101 






102 






103 


REQUEST JHALF_LINEFEED_JITCH PROCEDURE 


104 




ENTRY 


105 




SEND ( ASCII_ESC ) 


Append. 


Lx 
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106 SEND ( ']» ) 

107 SEND ( »R' ) 

108 END REQUEST_HALFJLINEFEED__PITCH 
109 

110 

1 1 1 REQUEST_STANDARD_LINEFEED_PITCH PROCEDURE 

112 ENTRY 

113 SEND ( ASCII_ESC ) 

114 SEND ( •]' ) 

115 SEND ( »W f ) 

116 END REQUESTJSTANDARD_LINEFEED_PITCH 
117 

118 

1 1 9 REQUEST_POS JALFJLINE PROCEDURE 

120 ENTRY 

1 2 1 REQUEST_HALF _LINEFEED__PITCH 

122 SEND ( f jL f ) 

1 23 REQUESTJSTANDARDJLINEFEEDJPITCH 

124 END REQUEST_POS_HALF_LINE 
125 

126 

127 REQUEST_NEG_HALF__LINE PROCEDURE 

128 ENTRY 

1 29 REQUEST_HALF_LINEFEEDJ?ITCH 

130 SEND ( ASCIIJESC ) 

131 SEND ( »9 f ) 

1 32 REQUEST_JSTANDARD_LINEFEEDJ?ITCH 

133 END REQUEST_NEG_HALF_LINE 
134 

135 

136 FORMFEED PROCEDURE 

137 ENTRY 

138 SEND ( ASCII_FF ) 

139 LINE_COUNT := 

140 LASTJSCRIPTJSTATE := 

141 SUPERSCRIPT.FLAG := FALSE 

142 SUBSCRIPT_FLAG := FALSE 
143 

144 IF PAGE__WAIT_FLAG = TRUE 

145 THEN 

146 PAGE_WAIT 

147 FI 
148 

149 END FORMFEED 

150 

151 

152 LINEFEED PROCEDURE 

153 ENTRY 

154 IF AUTO_FF_FLAG = TRUE 

155 THEN 

156 IF LINE_COUNT >= AUTO_FF_LINE_COUNT 

157 THEN 

158 FORMFEED 
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159 


RETURN 


160 


FI 


161 


FI 


162 




163 


SEND ( 'JL 1 ) 


164 


LINE_C0UNT += 1 


165 


END LINEFEED 


166 




167 




168 


REQUESTJFORWARD PROCEDURE 


169 


ENTRY 


170 


IF DIRECTION = FORWARD THEN RETURN FI 


171 


SEND ( ASCIIJESC ) 


172 


SEND ( •>• ) 


173 


DIRECTION := FORWARD 


174 


END REQUEST_FORWARD 


175 




176 




177 


REQUEST_BACKWARD PROCEDURE 


178 


ENTRY 


179 


IF DIRECTION = BACKWARD THEN RETURN FI 


180 


SEND ( ASCIIJESC ) 


181 


SEND ( f <» ) 


182 


DIRECTION := BACKWARD 


183 


END REQUEST_BACKWARD 


184 




185 




186 


REQUEST JBLACK PROCEDURE 


187 


ENTRY 


188 


SEND ( ASCII_ESC ) 


189 


SEND ( ! 4» ) 


190 


COLOUR := BLACK 


191 


END REQUEST JBLACK 


192 




193 




194 


REQUEST_RED PROCEDURE 


195 


ENTRY 


196 


SEND ( ASCIIJESC ) 


197 


SEND ( '3' ) 


198 


COLOUR := 


199 


END REQUESTED 


200 




201 




202 


DEFINE JiMI PROCEDURE ( SPACING BY' 


203 


ENTRY 


204 


SEND ( ASCIIJESC ) 


205 


SEND ( •]' ) 


206 


SEND ( SPACING + J40 ) 


207 


END DEFINE_HMI 


208 




209 




210 


SEND_BOLD_CHAR PROCEDURE ( CHAR BYTE , 


211 


ENTRY 
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212 
213 
214 
215 
216 
217 
218 
219 
220 
221 
222 
223 
224 
225 
226 
227 
228 
229 
230 
231 
232 
233 
234 
235 
236 
237 
238 
239 
240 
241 
242 
243 
244 
245 
246 
247 
248 
249 
250 
251 
252 
253 
254 
255 
256 
257 
258 
259 
260 
261 
262 
263 
264 



DEFINE _HMI ( ) 
SEND ( CHAR ) 

IF ( ATTRIBUTE AND UNDERLINE ) <> 
THEN 

SEND ( ASCIIJL ) 
FI 

DEFINE JMI ( 1 ) 
SEND ( CHAR ) 
DEFINE_HMI ( SS-1 ) 
SEND ( CHAR ) 
DEFINE_HMI ( SS ) 



END SEND_BOLD_CHAR 



ABSOLUTE__TAB 
ENTRY 



PROCEDURE ( COLUMN BYTE ) 



IF COLUMN > 162 THEN COLUMN := 162 FI 
SEND ( ASCII_ESC ) 

PRESENT_COLUMN := COLUMN 

IF COLUMN < 33 
THEN 

SEND ( f P' ) 

SEND ( J3F + COLUMN ) 

RETURN 

FI 

IF COLUMN < 65 
THEN 

SEND ( 'Q' ) 

SEND ( %1F + COLUMN ) 

RETURN 

FI 

IF COLUMN < 97 
THEN 

SEND ( 'R» ) 

SEND ( COLUMN - 1 ) 

RETURN 
FI 

IF COLUMN < 129 



THEN 



SEND ( f S' ) 

SEND ( COLUMN - J21 ) 

RETURN 



FI 



IF COLUMN < 161 
THEN 
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265 




SEND ( 'T f ) 


266 




SEND ( COLUMN - J41 ) 


267 




RETURN 


268 


FI 




269 






270 


SEND ( f U f ) 


271 


SEND ( COLUMN - *61 ) 


272 






273 END 


ABSOLUTEJTAB 


274 






275 






276 PRINT 


PROCEDURE ( CHAR BYTE ATTRIBUTE 


277 


ENTRY 




278 






279 


DO 




280 




IF ATTRIBUTE AND (SUBSCRIPT OR SUPERSCRIPT) 


281 




= LASTJSCRIPTJSTATE 


282 




THEN 


283 




EXIT 


284 




FI 


285 






286 




IF ATTRIBUTE AND SUPERSCRIPT <> 


287 




THEN 


288 




IF SUBSCRIPT_FLAG = TRUE 


289 




THEN 


290 




REQUEST_NEG_HALF__LINE 


291 




SUBSCRIPT.FLAG := FALSE 


292 




FI 


293 




REQUEST_NEG_HALF_LINE 


294 




SUPERSCRIPT_FLAG := TRUE 


295 




EXIT 


296 




FI 


297 






298 




IF ATTRIBUTE AND SUBSCRIPT <> 


299 




THEN 


300 




IF SUPERSCRIPTJFLAG = TRUE 


301 




THEN 


302 




REQUEST__POS_HALFJLINE 


303 




SUPERSCRIPT_FLAG := FALSE 


304 




FI 


305 




REQUEST_POS__HALF__LINE 


306 




SUBSCRIPT__FLAG := TRUE 


307 




EXIT 


308 




FI 


309 






310 




IF SUPERSCRIPT_FLAG = TRUE 


311 




THEN 


312 




REQUEST_POS_HALF_LINE 


313 




SUPERSCRIPT_FLAG := FALSE 


314 




EXIT 


315 




FI 


316 






317 




REQUEST_NEG_HALF_LINE 
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318 




SUBSCRIPT JFLAG := FALSE 


319 




EXIT 


320 






321 


OD 




322 






323 


LASTJSCRIPTJSTATE := ATTRIBUTE 


324 




AND ( SUPERSCRIPT OR SUBSCRIPT ) 


325 






326 


IF 


( ATTRIBUTE AND BLACK ) <> COLOUR 


327 




THEN 


328 




IF ( ATTRIBUTE AND BLACK ) = BLACK 


329 




THEN 


330 




REQUEST JBLACK 


331 




ELSE 


332 




REQUESTJRED 


333 




FI 


334 


FI 




335 






336 


IF 


CHAR > ASCIIJSPACE 


337 




THEN 


338 




IF ATTRIBUTE AND BOLD <> 


339 




THEN 


340 




SENDJBOLD__CHAR ( CHAR ATTRIBUTE ) 


341 




ELSE 


342 




IF ( ATTRIBUTE AND UNDERLINE ) <> 


343 




THEN 


344 




DEFINE__HMI ( ) 


345 




SEND ( CHAR ) 


346 




DEFINELPMI ( SS ) 


347 




SEND ( ASCIIJUL ) 


348 




ELSE 


349 




SEND ( CHAR ) 


350 




FI 


351 






352 




FI 


353 




ELSE 


354 




SEND ( CHAR ) ! SPACES WILL NOT BE UNDERL 


355 


FI 




356 






357 


IF 


DIRECTION = BACKWARD 


358 




THEN 


359 




PRESENTJ20LUMN -= 1 


360 




ELSE 


361 




PRESENT_COLUMN += 1 


362 


FI 




363 






364 


IF 


PRESENT_COLUMN = THEN PRESENT.COLUMN += 1 FI 


365 






366 






367 


END PRINT 




368 






369 






370 
Ippend 


ix 
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371 END SPINWRITER 
END OF ZCODE GENERATION 

ERROR (S) WARNING (S) 
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1 DIABLO MODULE 






c 

3 ! 


Extended 3/3/79 to allow 


for 


subscripting and superscr: 


4 ! 
5 
6 
7 


Also for operator controlled 


page_waits, and auto form 


CONSTANT 






8 
9 


PRINTER JUFFERJSIZE 






= 158 


10 


PITCH 






= 12 


11 


SS 






= 120/PITCH 


12 








13 


ASCII_ETX 






= $03 


14 


ASCII__ACK 






= ?06 


15 


ASCIIJESC 






= J1B 


16 


ASCIIJFF 






= $0C 


17 


ASCIIJBS 






= #08 


18 


ASCII_UL 






= i » 


19 


ASCII_SPACE 






_ t i 


20 


ASCII__US 






= %1F 


21 


ASCIIJTAB 






= ?09 


22 








23 


PARITY_MASK 




:= %7F 


24 








25 


FORWARD 




:= 1 


26 


BACKWARD 




:= 


27 








28 


BLACK 






= $01 


29 


BOLD 






= #02 


30 


UNDERLINE 






:= J04 


31 








32 


SUPERSCRIPT 






:= J08 


33 


NOT_SUPERSCRIPT 






= NOT SUPERSCRIPT 


34 


SUBSCRIPT 






= $10 


35 


NOTJSUBSCRIPT 






= NOT SUBSCRIPT 


36 








37 


TRUE 




:= 1 


38 


FALSE 




:= 


39 








40 


INTERNAL 






41 








42 


LINE__COUNT 




BYTE 


43 


COLOUR 




BYTE 


44 


HMI 




BYTE 


45 








46 


SUPERSCRIPT__FLAG 




BYTE 


47 


SUBSCRIPT J"LAG 




BYTE 


48 








49 


LASTJSCRIPTJSTATE 




BYTE 


50 








51 








52 


EXTERNAL 
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53 
54 
55 
56 
57 
58 
59 
60 
61 
62 
63 
64 
65 
66 
67 
68 
69 
70 
71 
72 
73 
74 
75 
76 
77 
78 
79 
80 
81 
82 
83 
84 
85 
86 
87 
88 
89 
90 
91 
92 

93 

94 

95 

96 

97 

98 

99 

100 

101 

102 

103 

104 

105 



0UTCH2 
INCH2 

PAGE_WAIT 

PAGE__WAIT_FLAG 
AUTO FF FLAG 



PROCEDURE ( BYTE ) 
PROCEDURE RETURNS ( BYTE ) 

PROCEDURE 

BYTE 
BYTE 



GLOBAL 



BYTE 
BYTE 
BYTE 
BYTE 
BYTE 



:= 158 



63 



PRINTER_WIDTH 
DIRECTION 
PRESENT_COLUMN 
AUT0_FF_LINE__C0UNT 
BYTE COUNT 



SENDJSTX PROCEDURE 

ENTRY 

0UTCH2 ( ASCIIJETX ) 

BYTE_COUNT := 
END SEND__ETX 



WAIT_FOR__ACK PROCEDURE 

ENTRY 
DO 

IF ( INCH2 AND PARITYJMASK ) = ASCII_ACK 
THEN 

RETURN 
FI 
OD 
END WAIT_FOR_ACK 



PROCEDURE 



SYNCH 

ENTRY 

IF BYTE__COUNT < PRINTERJBUFFER_SIZE 

SENDJSTX 

WAIT_FOR_ACK 
END SYNCH 



SEND PROCEDURE ( CODE BYTE ) 

ENTRY 

IF BYTE_COUNT > PRINTER_BUFFER_SIZE - 10 
THEN 

SENDJETX 
WAIT_FOR_ACK 
FI 
BYTE_COUNT += 1 



10 THEN RETURN FI 
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106 




OUTCH2 ( CODE ) 


107 


END 


SEND 


108 






109 






110 


FORMFEED PROCEDURE 


111 




ENTRY 


112 




SEND ( ASCII_FF ) 


113 




LINE_COUNT := 


114 




LASTJ5CRIPTJSTATE := 


115 




SUPERSCRIPTJFLAG := FALSE 


116 




SUBSCRIPT_FLAG := FALSE 


117 






118 




IF PAGEJNAITJFLAG = TRUE THEN PAGE_WAI' 


119 






120 


END 


FORMFEED 


121 






122 






123 


REQUEST .FORWARD PROCEDURE 


124 




ENTRY 


125 




IF DIRECTION = FORWARD THEN RETURN FI 


126 




SYNCH 


127 




OUTCH2 ( ASCIIJESC ) 


128 




0UTCH2 ( , 5 I ) 


129 




BYTE__COUNT += 2 


130 




DIRECTION := FORWARD 


131 


END 


REQUESTJFORWARD 


132 






133 






134 


REQUEST JACKWARD PROCEDURE 


135 




ENTRY 


136 




IF DIRECTION = BACKWARD THEN RETURN FI 


137 




SYNCH 


138 




0UTCH2 ( ASCIIJSSC ) 


139 




0UTCH2 ( »6 f ) 


140 




BYTE_COUNT += 2 


141 




DIRECTION := BACKWARD 


142 


END 


REQUESTJACKWARD 


143 






144 






145 


REQUEST_BLACK PROCEDURE 


146 




ENTRY 


147 




SYNCH 


148 




OUTCH2 ( ASCII__ESC ) 


149 




0UTCH2 ( »B f ) 


150 




BYTE_COUNT += 2 


151 




COLOUR := BLACK 


152 


END 


REQUEST JBLACK 


153 






154 






155 


REQUEST JED PROCEDURE 


156 




ENTRY 


157 




SYNCH 


158 




0UTCH2 ( ASCIIJSSC ) 
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159 0UTCH2 ( »A f ) 

160 BYTE__C0UNT += 2 

161 COLOUR := 

162 END REQUEST_RED 
163 

164 

165 LINEFEED PROCEDURE 

166 ENTRY 
167 

168 IF AUTOJFFJFLAG = TRUE 

169 THEN 

170 IF LINE_COUNT >= AUTO_FF_LINE_COUNT 

171 THEN 

172 FORMFEED 

173 RETURN 

174 FI 

175 FI 

176 SEND ( 'JL 1 ) 

177 LINEjCOUNT += 1 

178 END LINEFEED 
179 

180 

181 REQUEST JPOSJHALF_LINE PROCEDURE 

182 ENTRY 

183 SYNCH 

184 0UTCH2 ( ASCII__ESC ) 

185 0UTCH2 ( »U f ) 

186 BYTE_COUNT += 2 

187 END REQUESTJPOS_HALF_LINE 
188 

189 

190 REQUEST_NEG_HALF__LINE PROCEDURE 

191 ENTRY 

192 SYNCH 

193 OUTCH2 ( ASCII_ESC ) 

194 0UTCH2 ( 'D f ) 

195 BYTE_COUNT += 2 

196 END REQUEST_NEG_HALFJLINE 
197 

198 

199 DEFINE_HMI PROCEDURE ( SPACING BYTE ) 

200 ENTRY 

201 SYNCH 

202 OUTCH2 ( ASCII_ESC ) 

203 0UTCH2 ( ASCIIJUS ) 

204 OUTCH2 ( SPACING + 1 ) 

205 BYTE__COUNT += 3 

206 END DEFINE_HMI 
207 

208 

209 SEND_BOLD_CHAR PROCEDURE ( CHAR BYTE ATTRIBUTE BYTE ) 

210 ENTRY 

211 DEFINEJHMI ( ) 
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212 

213 
214 
215 
216 
217 
218 
219 
220 
221 
222 
223 
224 
225 
226 
227 
228 
229 
230 
231 
232 
233 
234 
235 
236 
237 
238 
239 
240 
241 
242 
243 
244 
245 
246 
247 
248 
249 
250 
251 
252 
253 
254 
255 
256 
257 
258 
259 
260 
261 
262 
263 
264 



SEND ( CHAR ) 

IF ( ATTRIBUTE AND UNDERLINE ) <> 
THEN 

SEND ( ASCII_UL ) 
FI 

DEFINEJMI ( 1 ) 
SEND ( CHAR ) 
DEFINE_HMI ( SS-1 ) 
SEND ( CHAR ) 
DEFINE_HMI ( SS ) 



END SEND BOLD CHAR 



ABSOLUTE TAB 



PROCEDURE ( COLUMN BYTE ) 



LOCAL RESIDUE BYTE 
DIR BYTE 



ENTRY 



IF COLUMN > 156 THEN COLUMN := 156 FI 

SYNCH 

OUTCH2 ( ASCIIJSSC ) 

0UTCH2 ( ASCIIJTAB ) 

BYTE__C0UNT += 2 

PRESENT__COLUMN := COLUMN 

IF COLUMN <= 126 
THEN 

OUTCH2 ( COLUMN ) 

BYTE_COUNT += 1 

RETURN 
FI 

RESIDUE := COLUMN - 126 
0UTCH2 ( 126 ) 
BYTE_COUNT +r 1 
DIR := DIRECTION 
REQUEST JFORWARD 



DO 



IF RESIDUE = 
THEN 

IF DIR = BACKWARD 
THEN 

REQUEST JBACKWARD 
FI 

RETURN 
FI 
SEND ( ASCIIJSPACE ) 



Appendix 



6-46 



DIABLO 



Spinwriter /Diablo driver Revision 2.1 



265 




RESIDUE -= 1 


266 


0D 






267 








268 


END ABSOLUTEJTAB 


269 








270 








271 


PRINT 




PROCEDURE ( CHAR BYTE ATTRIBUTE 


272 


ENTRY 






273 








274 








275 


DO 






276 




IF 


ATTRIBUTE AND (SUBSCRIPT OR SUPERSCRIPT) 


277 






= LAST_SCRIPT_STATE 


278 






THEN 


279 






EXIT 


280 




FI 




281 








282 




IF 


ATTRIBUTE AND SUPERSCRIPT <> 


283 






THEN 


284 






IF SUBSCRIPT_FLAG = TRUE 


285 






THEN 


286 






REQUEST_NEG_HALF_LINE 


287 






SUBSCRIPTJFLAG := FALSE 


288 






FI 


289 






REQUEST_NEG__HALF_LINE 


290 






SUPERSCRIPT_FLAG := TRUE 


291 






EXIT 


292 




FI 




293 








294 




IF 


ATTRIBUTE AND SUBSCRIPT <> 


295 






THEN 


296 






IF SUPERSCRIPT_FLAG = TRUE 


297 






THEN 


298 






REQUEST_POS_HALF_LINE 


299 






SUPERSCRIPT_FLAG := FALSE 


300 






FI 


301 






REQUEST__POS_HALF_LINE 


302 






SUBSCRIPT_FLAG := TRUE 


303 






EXIT 


304 




FI 




305 








306 




IF 


SUPERSCRIPT_FLAG = TRUE 


307 






THEN 


308 






REQUEST_POS_HALF__LINE 


309 






SUPERSCRIPT_FLAG := FALSE 


310 






EXIT 


311 




FI 




312 








313 




REQUEST_NEG_HALF_LINE 


314 




SUBSCRIPT_FLAG := FALSE 


315 




EXIT 


316 








317 


OD 
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318 

3 1 9 LASTJSCRIPTJSTATE 

320 := ATTRIBUTE AND ( SUPERSCRIPT OR SUBSCRIPT ) 

321 IF ( ATTRIBUTE AND BLACK ) <> COLOUR 

322 THEN 

323 IF ( ATTRIBUTE AND BLACK ) = BLACK 

324 THEN 

325 REQUEST_BLACK 

326 ELSE 

327 REQUEST JED 

328 FI 

329 FI 
330 

331 IF CHAR > ASCII JSPACE 

332 THEN 

333 IF ATTRIBUTE AND BOLD <> 

334 THEN 

335 SEND_BOLD_CHAR ( CHAR ATTRIBUTE ) 

336 ELSE 

337 IF ( ATTRIBUTE AND UNDERLINE ) <> 

338 THEN 

339 DEFINE_HMI ( ) 

340 SEND ( CHAR ) 

341 DEFINE_HMI ( SS ) 

342 SEND ( ASCIIJUL ) 

343 ELSE 

344 SEND ( CHAR ) 

345 FI 
346 

347 FI 

348 ELSE 

349 SEND ( CHAR ) ! SPACES WILL NOT BE UNDERLINED ! 

350 FI 
351 

352 IF DIRECTION = BACKWARD 

353 THEN 

354 PRESENT_COLUMN -= 1 

355 ELSE 

356 PRESENT_COLUMN += 1 

357 FI 
358 

359 IF PRESENT_COLUMN = THEN PRESENT_COLUMN += 1 FI 

360 
361 

362 END PRINT 
363 
364 
365 

366 END DIABLO 
END OF ZCODE GENERATION 

ERROR (S) WARNING (S) 
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Call to SYSTEM CALL. SYSTEM 

LOC OBJ CODE M STMT SOURCE STATEMENT 



PAGE 1 
ASM 5.8 



0000 

0008 

000E E5 

O00F FDE1 

0011 DDE5 

0013 CD0314 

0016 DDE1 



0018 
00 1B 

001E 



FD7E0A 



1 
2 
3 
133 
134 
135 
136 
137 
138 
139 
140 
141 
142 
143 
144 
145 
146 
147 
148 
149 
150 
151 
152 
153 
154 

155 
156 
157 
158 
159 
160 
161 
162 
163 
164 
165 
166 
167 
168 
169 



*H Call to SYSTEM 

•I PLZ. INTERFACE. MACROS 

*LIST ON 

"MACLIST OFF 

; Date_code:- October 22nd. 1978. 

; This interface module allows a PLZ programme to make 
; calls to RIO. 

; Declare CALRIO PROCEDURE ( VECTOR_PTR "byte ) 

; RETURNS ( C0MPLETI0N_C0DE byte ) 

; There must be a standard RIO request vector stored 
; starting at the location beginning VECTOR_PTR" 

global CALRIO calrio 

SYSTEM EQU 1403H 



CALRIO 
calrio 
ENT 

LDHL 4 
push hi 
pop iy 



; no locals 

; put RIO vector address into hi 

; and then where it should be 



push ix ; save it 

call SYSTEM ; go and do the necessary 

pop ix ; restore it 

Id a,(iy+10) ; get the completion code 

STA 6 ; and place it as return parameter 

RTN 2 ; return to caller. locals, 2 I/P param bytes 



END 
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CALL. SYSTEM 
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RIO . 10 . INTERFACE RIO . 10 . INTERFACE 

LOC OBJ CODE M STMT SOURCE STATEMENT 



PAGE 
ASM 



1 
5.8 







1 
2 
3 


*H RIO. 10. INTERFACE 








4 
5 
6 


; Date___code : - October 31s 


t. 1978 






; This interface module receives I/O calls from RIO, and 






7 


; passes the IY register 


value to the called programme 






8 

9 

10 


; as a single parameter. 








; The intention of the module is to act as an interface 






11 


; to enable I/O drivers 


to be written largely in PLZ. 






12 










13 










14 


EXTERNAL PLZDVR 








15 










16 


GLOBAL ENTRY entry 






17 










18 


ENTRY 








19 


entry 








20 






0000 


FDE5 


21 
22 


push iy ; 


the actual parameter 


0002 


FD223000 R 


23 
24 


LD (IY_SAV),IY ; 


save iy 


0006 


CD0000 X 


25 
26 


call PLZDVR ; 


pass control to the driver proper 


0009 


FD2A3000 R 


27 
28 


LD IY,(IY__SAV) ; 


restore iy 


O00D 


FDCB0146 


29 


bit 0,(iy+1) ; 


was it int.req ? 


0011 


FD7E0A 


30 


Id a,(iy+10) ; 


get encode 


0014 


200E 


31 


jr nz,intreq 




0016 


FE80 


32 


cp 80h ; 


was it good ? 


0018 


C8 


33 
34 


ret z ; 
getera 


if so, go back quietly 


0019 


FD6609 


35 


Id h,(iy+9) 




001C 


FD6E08 


36 
37 


Id l,(iy+8) 
jmpret 




001F 


7C 


38 


Id a,h 




0020 


B5 


39 


or 1 




0021 


C8 


40 


ret z ; 


rtn add field was zero 


0022 


C1 


41 


pop be ; 


balance stack 


0023 


E9 


42 


jp (hi) 




0024 


FE80 


43 


intreq cp 80h 




0026 


20F1 


44 


jr nz, getera 




0028 


FD6607 


45 


Id h*(iy+7) 




002B 


FD6E06 


46 


Id l,(iy+6) 




002E 


18EF 


47 
48 
49 
50 


jr jmpret ; 
IYJSAV 


check era field 
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0030 51 defs 2 

52 
53 end 
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SIB CH2 input/output SIB 
LOC OBJ CODE M STMT SOURCE STATEMENT 



PAGE 1 
ASM 5.8 



1 
2 
3 
4 
134 
135 
136 
137 
138 
139 
140 
141 
142 
143 
144 
145 
146 
147 
148 
149 
150 
151 
152 
153 
154 
155 
156 
157 
158 
159 
160 
161 
162 
163 
164 
165 
166 

167 
168 
169 
170 
171 
172 

173 



*H SIB CH2 input/output 
*P 50 

*I PL Z . INTERFACE . MACROS 
*LIST ON 
*MACLIST OFF 

; Date_code:- October 23rd. 1978. 

; This module contains the routines which enable a PLZ 
; programme to be involved with I/O through channel 2 
; of an SIB installed in the system. 

; The calling programme should contain the following 
; declarations :- 

EXTERNAL 

0UTCH2 PROCEDURE ( BYTE ) 

! send, with wait ready ! 



INCH2 PROCEDURE 



INCH2E PROCEDURE 



STACH2 PROCEDURE 



RETURNS ( BYTE ) 

! input, with wait ready ! 

RETURNS ( BYTE ) 

! input, wait ready, echo ! 

RETURNS ( BYTE ) 

! read status of USART2 ! 



SNDCH2 PROCEDURE ( BYTE ) 

! send, without wait ready ! 

RDCH2 PROCEDURE RETURNS ( BYTE ) 

! read, without wait ready ! 



SETCH2 PROCEDURE 



! set up USART2 + CTC baud rate ! 



global 0UTCH2 INCH2 INCH2E 

global STACH2 SNDCH2 RDCH2 SETCH2 

global outch2 inch2 inch2e 

global stach2 sndch2 rdch2 setch2 
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SIB CH2 input/output SIB 

LOC OBJ CODE M STMT SOURCE STATEMENT 



PAGE 2 
ASM 5.8 









174 


*E 








175 










176 


SETCH2 








177 


setch2 


0000 






178 
179 


ENT 


0008 


CD9400 


R 


180 


call BAUDR 


000B 


CD7B00 


R 


181 
182 


call SUART2 


000E 






183 
184 
185 
186 
187 


RTN 

0UTCH2 
outch2 


0011 






188 
189 


ENT 


0019 






190 


LDA 4 


001C 


CDA600 


R 


191 
192 


call 0USIB2 


001F 






193 
194 
195 
196 
197 


RTN 2 

INCH2 
inch2 


0024 






198 
199 


ENT 


002C 


CD9D00 


R 


200 


call INSIB2 


002F 






201 
202 


STA 4 


0032 






203 
204 
205 
206 
207 


RTN 

INCH2E 
inch2e 


0035 






208 
209 


ENT 


003D 


CD9D00 


R 


210 


call INSIB2 


0040 


CDA600 


R 


211 


call 0USIB2 


0043 






212 
213 


STA 4 


0046 






214 
215 
216 
217 
218 


RTN 

STACH2 
stach2 


0049 






219 
220 


ENT 


0051 


DB91 




221 


in a,(USART2+1) 


0053 






222 
223 


STA 4 


Append 


ix 
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; set up the baud rate 
; set up USART-2 

; no locals, no IN parameters 



; get the code for issuing 
; send it with wait ready 

; no locals, 2 bytes IN 



; get the code, with wait ready 
; place it as return parameter 

; no locals, no IN parameters 



; get the code, with wait ready 

; echo it, with wait ready 

; place code as return parameter 

; no locals, no IN parameters 



get the status reg contents 
place it as return parameter 



SIB 
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SIB CH2 input/output SIB 
LOC OBJ CODE M STMT SOURCE STATEMENT 



PAGE 3 
ASM 5.8 



0056 



0059 

0061 
0064 

0066 



006B 

0073 
0075 

0078 



224 RTN 

225 

226 

227 SNDCH2 

228 sndch2 

229 ENT 
230 

231 LDA 4 
D390 232 out (USART2),a 
233 

234 RTN 2 
235 
236 

237 RDCH2 

238 rdoh2 

239 ENT 
240 

DB90 241 in a,(USART2) 
242 STA 4 
243 

244 RTN 
245 
246 *I SIB. CONTROL 



; no locals, no IN parameters 



; get the code to be sent 
; send it immediately 

; no locals, 2 bytes IN parameters 



; get data reg contents 

; place it as return parameter 

; no locals, no IN parameters 
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LOC OBJ CODE M STMT SOURCE STATEMENT 



PAGE 4 
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007B 


0E91 


007D 


AF 


007E 


ED79 


0080 


ED79 


0082 


ED79 


0084 


3E40 


0086 


ED79 


0088 


3ECE 


008A 


ED79 


008C 


3E37 


00 8E 


ED79 


0090 


OD 


0091 


ED78 


0093 


C9 



0094 3E07 

0096 D381 

0098 3E04 

009A D381 

009C C9 



247 


*H SIB 


CONTROL 




248 








249 








250 








251 


.ft************************************************** 


252 


; RESET AND SET UP USART2 


253 


. *************************************************** 


254 








255 


SUART2 


LD C,USART2+1 


USART2 - CONTROL REGISTER 


256 




XOR A 




257 




OUT (C),A 


THREE INTERNAL RESETS = EXT R 


258 




OUT (C),A 




259 




OUT (C),A 




260 




LD A,40H ; 


INT RESET 


261 






ENTER MODE INSTRUCTION FORMAT 


262 




OUT (C),A 




263 




LD A,OCEH ; 


8xDATA + 2xST0P BITS 


264 






NO PARITY, 16xBAUD RATE 


265 




OUT (C),A 




266 




LD A,37H 


RTS, ERROR RESET 


267 






REC ENABLE, DTR, XMIT ENABLE 


268 




OUT (C),A 




269 




DEC C 




270 




IN A,(C) 


CLEAR OUT GARBAGE CHARACTER 


271 




RET 




272 








273 








274 


USARTO 


EQU 8CH 




275 


USART1 


EQU 8EH 




276 


USART2 


EQU 90H 




277 


US ART 3 


EQU 92H 




278 








279 








280 








281 








282 


;*************************************************** 


283 


; SET 


UP CTC1 TO GENERATE THE BAUD RATE 


284 


. ft******************************* ******************* 


285 








286 


BAUDR 


LD A,TIMMOD 


TIMER MODE ETC 


287 


OUT 


(CTC1),A 




288 


LD 


A,RATEO 


WITH RATE IN RATEO 


289 


OUT 


(CTC1),A 




290 


RET 






291 








292 








293 


CTCO 


EQU 80H 


ADDRESS OF CTCO 


294 


CTC1 


EQU 81H 


ADDRESS OF CTC1 


295 


CTC2 


EQU 82H 


ADDRESS OF CTC2 


296 


CTC3 


EQU 83H 


ADDRESS OF CTC3 
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SIB CONTROL SIB 

LOC OBJ CODE M STMT SOURCE STATEMENT 



PAGE 
ASM 



5.8 



009D 


DB91 


009F 


CB4F 


00A1 


28FA 


00A3 


DB90 


O0A5 


C9 


O0A6 


F5 


00A7 


DB91 


O0A9 


CB47 


OOAB 


28FA 


OOAD 


F1 


OOAE 


D390 


OOBO 


C9 



297 








298 


TIMMOD 


EQU 07H i 


TIMER MODE, PRESCALER=16 


299 




: 


INT. DISABLED, RESET 


300 








301 


RATEO 


EQU 4 ; 


FOR 1200 BAUDS 


302 








303 








304 








305 


.ft************************************************** 


306 


; ELEMENTARY CHARACTER 


LEVEL I/O 


307 


. *«ftfttft*«»tt****ftftft*«***ft****tt*******ft***ft*««****#ft*« 


308 








309 


INSIB2 


IN A,(USART2+1) 


GET STATUS REGISTER 


310 




BIT RXRDY, A 


IS THE RECEIVER FLAG SET 


311 




JR Z,INSIB2 ; 


IF NOT, WAIT FOR IT 


312 




IN A,(USART2) 


GET CONTENT OF DATA REGISTER 


313 




RET 




314 








315 








316 


0USIB2 


PUSH AF 


SAVE CHARACTER 


317 


BZY 


IN A,(USART2+1) 


GET STATUS REGISTER 


318 




BIT TXRDY, A 


TEST THE TRANSMITTER READY FLAG 


319 




JR Z,BZY 


IF UNREADY THEN WAIT 


320 




POP AF 


RESTORE CHARACTER CODE 


321 




OUT (USART2),A 


SEND IT 


322 




RET 




323 








324 








325 


RXRDY 


EQU 1 


RECEIVER READY BIT 


326 


TXRDY 


EQU 


TRANSMITTER READY BIT 


327 
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LOC OBJ CODE M STMT SOURCE STATEMENT ASM 5.8 

1 ;*LIST OFF 

2 

3 

4 ; Mark-stack macro: 

5 

6 ; Allocate room on stack for out parameters 

7 ; before a procedure call. 
8 

9 ; Optimise the code when 0,1, or 2 parameters 

10 ; ie. 0,2 or 4 bytes. 
11 

12 MST macro #n ; #n is in BYTES »** 

13 cond (#n=2).or.(#n=4) 

14 push hi 

15 cond #n=4 

16 push hi 

17 endc 

18 cond .not.(#n=0) .and. .not.(#n=2) .and. .not.(#n=4) 

19 id hl,-#n 

20 add hl,sp 

21 Id sp,hl 

22 endc 

23 endm 
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LOC OBJ CODE M STMT SOURCE STATEMENT ASM 5.8 



24 


*E 




25 






26 


; Procedure entry: 


27 






28 


; Allocate locals on stack ( No. of bytes ) 


29 






30 


; Opt: 


Lmise when 0,2, or 4 bytes. 


31 






32 


ENT 


macro #n ; #n is in BYTES *** 


33 




push ix 


34 




Id ix,0 


35 




add ix,sp 


36 




cond (#n=2).or.(#n=4) 


37 




push hi 


38 




cond #n=4 


39 




push hi 


40 




endc 


41 




cond .not.(#n=0) .and. .not.(#n=2) .and. .not.(#n=4) 


42 




Id hl,-#n 


43 




add hl,sp 


44 




Id sp,hl 


45 




endc 


46 




endm 
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LOC OBJ CODE M STMT SOURCE STATEMENT ASM 5.8 



47 


*E 


48 




49 


; Procedure return: 


50 




51 


; Deallocate locals ( bytes ) and IN parameters. 


52 




53 


; Optimise when 0,2, or 4 bytes. 


54 




55 


RTN macro #L f #n ; #L, #n are in BYTES *** 


56 




57 


cond #L 


58 


Id sp,ix 


59 


endc 


60 




61 


pop ix 


62 




63 


cond #n=0 


64 


ret 


65 


endc 


66 




67 


cond (#n=2).or.(#n=4) 


68 


pop hi 


69 


pop de 


70 




71 


cond #n=4 


72 


pop de 


73 


endc 


74 




75 


cond (#n=2).or.(#n=4) 


76 


jp (hi) 


77 


endc 


78 




79 


cond .not.(#n=0) .and. .not.(#n=2) .and. ,not.(#n=4) 


80 


pop de 


81 


Id hl,#n 


82 


add hl,sp 


83 


Id sp,hl 


84 


ex de,hl 


85 


jp (hi) 


86 


endc 


87 




88 


endm 
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LOC OBJ CODE M STMT SOURCE STATEMENT ASM 5.8 

89 *E 
90 

91 ; Macros for accessing locals and parameters 

92 ; from the stack. 
93 

94 ; This is only a small selection. 

95 

96 

97 

98 ; Load hi from #n ( offset of word variable from ix ) 

99 

100 LDHL macro #n 

101 Id l,(ix+#n) 

102 Id h,(ix+#n+1) 

103 endm 
104 

105 

106 

107 ; Store hi into #n ( offset of word variable from ix ) 

108 

109 STHL macro #n 

110 Id (ix+#n),l 

111 Id (ix+#n+1),h 

112 endm 
113 

114 

115 

116 ; Load A from #n ( offset of byte variable from ix ) 

117 

118 LDA macro #n 

119 Id a,(ix+#n) 

120 endm 
121 

122 

123 

124 ; Store A into #n ( offset of byte variable from ix ) 

125 

126 STA macro #n 

127 Id (ix+#n),a 

128 endm 
129 

130 *LIST ON 
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ZRTS 8000 

Zilog Real-Time Software 

lor the Z8000 Microprocessor 



Zilog 



Product 
Description 



Preliminary 



June 1981 




Real-time Multi-tasking Software 
Components 

o Synchronization of multiple tasks 

• Interrupt-dnven priority schedul- 
ing 

o Real-time response 

o Dynamic memory allocation 

Modular and Flexible Design 

o Efficient memory utilization 

o 4K byte PROMable kernel 

o Support for Z8001 and Z8002 
16-bit microprocessors 

o Configurable via linkable 
modules 

Versatile Base for Z8000™ System 
Designs 

o Segmented/non-segmented tasks 

o System/normal mode tasks 

o Uses standard Zilog calling con- 
ventions 



■ Easy-To-Use System Generator 

o High-level configuration 
language 

o Supports a wide variety of hard- 
ware configurations 

O Easily changed control 
parameters allow system 
optimization 

o Eliminates the requirement for 
intimate knowledge of system in- 
ternal structure 

OVERVIEW 

Zilog's Real Time Software (ZRTS) 
provides of a set of modular software 
components that allows quick and easy 
implementation of customized 
operating systems for all members of 
the Z8000 16-bit microprocessor family. 
In effect, ZRTS extends the instruction 
set of the Z8000, adding easy-to-use 
commands that give the Z8000 the 
capability for managing real-time, 
multi-tasking applications. 



The ZRTS package consists of a 
small real-time, multi-tasking executive 
program, the Kernel, and a System 
Configurator. The Kernel provides 
sychromzation and control of multiple 
events occurring in a real-time en- 
vironment. All major real-time func- 
tions are available — task synchroniza- 
tion, mterrupt-dnven priority schedul- 
ing, intertask communication, real-time 
response, and dynamic memory alloca- 
tion. The System Configurator is a 
language processor that allows the 
target operating system to be defined 
m high-level terms using the ZRTS 
Configuration Language (ZCL). 




These functions greatly simplify the 
tasks of the designer, allowing 
development efforts to be concentrated 
on the application, instead of on real- 
time coordination, task management 
problems, and complicated system 
generations. ZRTS provides a modular 
and flexible development tool that 
serves as a versatile base for Z8000 
system designs. The Kernel requires 
only 4K bytes of either PROM or RAM 
memory, thus allowing configurations 
for a wide variety of target systems, 
while producing a memory-efficient, 
cost-effective end product. 
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FUNCTIONAL DESCRIPTION 

The Concepts. ZRTS is both easy-to- 
learn and easy-to-use. Only a few sim- 
ple concepts need to be understood 
before designing begins. 

Tasks. Tasks are the components com- 
prising a real-time application. Each 
task is an independent program that 
shares the processor with the other 
tasks in the system. Tasks provide a 
mechanism that allows a complicated 
application to be subdivided into 
several independent, understandable, 
and manageable units. 

Semaphores. Semaphores provide a 
low overhead facility for allowing one 
task to signal another. Semaphores can 
be used for indicating the availability 
of a shared resource, timing pulses or 
event notification. 

Exchanges and Messages. Exchanges 
and Messages provide the mechanism 
for one task to send data to another. A 
Message is a buffer of data, while an 
Exchange serves as a mailbox at which 
tasks can wait for Messages and to 
which Messages are sent and held. 

The ZRTS Kernel. The Kernel is the 
basic building block of ZRTS and per- 
forms the management functions for 
tasks, semaphores, the real-time clock, 
memory and interrupts. The Kernel 
also provides for task-to-task com- 
munications via Exchanges and 
Messages. All requests for Kernel 
operations are made via system call 
instructions with parameters in 
registers, according to the standard 
Zilog calling conventions. 
Task Management. One of the main 
activities of the Kernel is to arbitrate 
the competition that results when 
several tasks each want to use the pro- 
cessor. Each task has a unique task 
descriptor that is managed by the 
Kernel. The data contained in the 
descriptor include the task name, 
priority, state and other pertinent 
status information. ZRTS supports any 
number of tasks, limited only by the 
memory available to accommodate the 
task descriptors and stacks. 

The Kernel maintains a queue of all 
active tasks on the system. Each task is 
scheduled for processor time based on 
its priority. The highest-priority task 
that's ready to run gains control of the 
CPU; other tasks are queued. Tasks 
can be prioritized up to 32767 levels, 
with round-robin scheduling among 
tasks with the same priority. 

Tasks can run either segmented or 
non-segmented code, in either normal 
or system mode, The numerous opera- 
tions that may be performed on tasks 
are listed in Table I. 



TABLE 1. 



TASK MANAGEMENT 

T Census 

T Create 

T Destroy 

T Lock 

T Reschedule 

T Resume 

T Suspend 

T_Unlock 

T__Wait 

SEMAPHORE MANAGEMENT 

Sem Clear 

Sern Create 

Sem Destroy 

Sem Signal 

Sem Test 

Sem Wait 

CLOCK MANAGEMENT 

Clk__Delay__Absolute 

Clk_Delay__Interval 

Clk_Set 

Clk__Time 

MEMORY MANAGEMENT 

Mem Census 

Alloc 

Release 

INTER-TASK COMMUNICATION 

M Acquire 

M Assign 

M Create 

M Destroy 

M__Get .Descriptor 

M_Read 

M Receive 

M Receive Wait 

M Release 

ML_Reply 

M Send 

M_Write 
X Create 

X Destroy 



Provides the status of tasks in the 
system. 

Creates a task dynamically 

Removes a dynamically created task 

Allows a task to take exclusive control 
of the CPU. 

Changes the priority of a task. 

Activates a suspended task. 

Suspends another task. 

Releases exclusive control of the CPU 
for other tasks. 

Suspends task execution 



Clears semaphore queue and 
reinitializes a semaphore. 

Creates a semaphore dynamically 

Removes a dynamically created 
semaphore. 

Signals a semaphore, increments the 
counter. 

Tests a semaphore for a signal. 

Causes a task to wait until a semaphore 
is signaled, decrements the counter. 

Places a task on the clock queue 
waiting for absolute time. 

Places a task on the clock queue 
waiting for passage of an interval of 
time 

Sets the real-time clock. 

Reads the clock. 

Provides status of the memory 
resource. 

Dynamically allocates memory. 

Releases allocated memory. 

Gets a message from an exchange pool 
and assign's a destination or a reply 
exchange to it. 

Assigns a new source and destination 
to an existing message. 

Creates a message dynamically. 

Removes a dynamically created 
message. 

Gets message's descriptor information 

Reads the message data. 

Receives a message from an exchange 

Waits to receive a message from an 
exchange. 

Returns a message to the exchange 
pool. 

Sends a message back to destination 
exchange. 

Sends a message to an exchange. 

Changes message data. 

Dynamically creates an exchange with 
a pool of messages. 

Removes a dynamically created 
exchange. 
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Semaphore Management. The Kernel 
provides semaphore management for 
synchronizing interacting tasks. A 
typical use of semaphores is to provide 
mutual exclusion of a shared resource. 
When a resource is to be used by only 
one task at a time, a semaphore with a 
counter of 1 controls the resource. 
Every task requiring the resource must 
first wait on that semaphore. Since the 
counter is 1 , only one task will acquire 
the resource. The others will be 
queued on the semaphore and 
suspended until the semaphore is 
signaled that the resource is once 
again available. At that time, the -first 
task on the semaphore queue will be 
made ready to run and can use the 
resource. After all tasks have acquired 
the resource and signaled the comple- 
tion of their use, the semaphore returns 
to its original state with a counter of 1 . 
Counters greater than one are useful 
when there are a number of similar 
resources, (i.e., three tape drives, four 
I/O buffers, etc.). 

In ZRTS, a semaphore can count up 
to 32676 signals. The commands pro- 
vided by the Kernel to manage 
semaphores are listed in Table 1. 

Clock Management. ZRTS operates 
with a real-time clock that generates 
interrupts at a hardware- dependent 
rate. It is used for timed waits, 
timeouts, and round-robin scheduling. 
All times are given in number of ticks. 
The clock may be manipulated by the 
set of commands provided by the 
Kernel that are listed in Table 1. 

Memory Management. Storage for 
ZRTS data structures is allocated either 
statically at system generation time, or 
dynamically at run time. Dynamic 
allocation occurs via a system call that 
specifies the attributes of the structure 
to be created and returns a name that 
can be used to refer to the structure. 
Memory is allocated in 256-byte 
increments, and can be released using 
a system call. 

The storage allocator can also be 
called directly to obtain blocks of 
memory up to 64K bytes long, which 
can be used by the task for any pur- 
pose. 

Interrupt Management. Interrupt- 
handlmg routines are provided for 
system calls, non- vectored interrupts 
and a hardware clock. The user must 
provide interrupt routines for whatever 
other vectored interrupts are included 
in the target system. 

ZRTS can switch control to a task 
waiting for an external event within 
500-microseconds after the occurrence 
of the event. This is based on the worst 
case with a 4MHz Z8000. A more typi- 
cal response time would be 



TABLE 2. 



CONSTANTS 
EXCHANGES 

FILES 

HARDWARE 

INITIALIZATION 

INTERRUPT 



MEMORY 

SECTIONS 

SEMAPHORES 

SWITCHES 

TASKS 



Specifies system constants. 

Defines the characteristics of applica- 
tion exchanges. 

Indicates additional files to be included 
m the configuration link. 

Describes the target hardware con- 
figuration— Z8001, Z8002, or Develop- 
ment Module. 

Specifies routines that are to execute 
prior to beginning execution of the first 
task. 

Associates an interrupt routine with an 
interrupt vector or trap and system 
call-handlers. Provides the facilities to 
specify a NVI interrupt-handler that 
will be called from the system NVI- 
handler routine. 

Specifies the memory configuration 
and identifies where sections are to be 
placed (i.e.,CODE,DATA,...). 

Allows modules to be placed in a 
specific section, overriding the stan- 
dard assignment conventions. 

Defines the characteristics of applica- 
tion semaphores. 

Allows flags that control the system 
generation operation to be set. 

Defines the characteristics of applica- 
tion tasks. 



250-microseconds. Quicker service of 
interrupts is possible through the use 
of user- written routines. 

Inter-task Communication. The 

Kernel provides the capability for tasks 
to exchange information. This com- 
munication process occurs when one 
task sends a Message to an Exchange 
and another task receives the Message. 

A Message contains a length indi- 
cator, a buffer with a variable amount 
of data, and a code that identifies the 
Message type. The Exchange is a 
system data structure that consists of a 
queue for Messages sent but not yet 
received, a semaphore on which a task 
can wait for a Message, and an 
optional "pool" list from which 



Messages can be obtained quickly. 

ZRTS provides several commands for 
inter-task communications. These are 
listed in Table 1. 

ZRTS Configuration Language (ZCL). 

Since ZRTS's modular design leads to 
so many different configurations, a 
simple facility for generating the target 
operating system is a critical part of 
the ZRTS package. The ZRTS Con- 
figuration Language (ZCL) provides an 
easy-to-use means for generating the 
target system. Using ZCL, the designer 
can specify hardware information, soft- 
ware parameters, linkage information, 
and system data structures in high- 
level terms. 




SYSTEM 
CONFIGURATION 



USER 
APPLICATION 



Z8000 
DEVELOPMENT 
/ :s \MODULE 




Development Environment 
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ZCL unburdens the user of the 
necessity to learn the details of the 
ZRTS internal structures. System data 
structures can be generated simply by 
specifying the appropriate parameters. 
The ZCL syntax is free-format with 
comments allowed to make the con- 
figuration commands more readable 
and maintainable. 

ZCL input is comprised of a number 
of descriptive sections, each containing 
the details of the target operating 
system. The functions of these sections 
are described in Table 2. A sample 
system generation using ZCL is il- 
lustrated in Figure 1. 

Development Environment. Applica- 
tion modules for ZRTS can be 
developed on any Zilog Z80 or 
Z8000-based development system and 
then down-loaded into a Zilog Develop- 
ment Module or a customized target 
system. 

Subroutine libraries are provided for 
making ZRTS systems calls from pro- 
grams written in PLZ/SYS, PLZ/ASM 
and C. Register usage in the system 
calls is compatible with the Zxlog 
standard. 

When using a Development Module, 
the Debugger can be used with the 
ZRTS modules for testing purposes. 
After the application is debugged, the 
system can be easily reconfigured for 
the final target hardware. 



SWITCHES : 

APPLICATION 
HARDWARE : 

Z8002 
INTERRUPTS : 
CONSTANTS : 

MINIMUM_SYSTEM_STACK_SIZE = ! 
FILES: 

REAL_TIME_CLOCK; 

MEMORY : 

CODE = [%8000..%8FFF] ; 
DATA = [%9000..%9FFF] ; 
FREE MEMORY = [%F000 . . %FFFF] 



INITIALIZATION: 



input handler_task = 
tim_dlsplay_task = 
egg_timer task = 
alarm_tasl< = 
one_second_task = 

SEMAPHORES : 



[entry = INPUT HANDLER, priority = 10] 

[entry = TIMEJ5ISPLAY, priority = 20] 

[entry = EGG_TIMER, priority = 20] 

[entry = ALARM, priority = 20] 

[entry = ONE SECOND_GENERATOR, priority = 30] 



ONE_SECOND_SEMAPHORE ; 

TIME DISPLAY ENABLE SEMAPHORE; 



EXCHANGES: 



INPUT HANDLER ETE EXCHANGE 



ALARM EXCHANGE 



[number_of messages = 1, 

message_slze = 8] ; 

[number_of_messages = 0] ; 

[number_of_messages = 1, 

message_size = 8] ; 

[number__of_messages = 0] ; 



Figure 1. ZCL Sample Input. 



ORDERING INFORMATION 

Description 

ZRTS/8001 Zilog Real Time Software for the Z8001 
ZRTS/8002 Zilog Real Time Software for the Z8002 



Prerequsites 

Zilog Development System 

MCZ/1, PDS, ZDS Series or Z-LAB 8000 (Reguires Software License) 
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Peripheral controller chip 
ties into 8- and 16-bit systems 

Based on one-chip-microcomputer architecture, universal peripheral controller 
comes with either multiplexed or nonmultiplexed address and data lines, 
provides ROM-less and prototyping packages for product development 



by John Banning and Pat Lin, zuoginc, Cupertino, cam 



□ The growing power of high-end microprocessors and 
the complexity of peripheral devices attached to them 
has given rise to a need for general-purpose distributed 
processors to handle increasingly complicated input/out- 
put activities. As such, these devices must themselves 
have respectable processing and l/O-manipulation abili- 
ties while being able to interact efficiently with high-end 
microprocessors. Ideally, they would also communicate 
with 8-bit midrange microprocessors and be low in cost. 

Just such a processor has been based on the Z8 
single-chip microcomputer. The Z-UPC universal periph- 
eral controller combines the instruction and I/O capabili- 
ty of the Z8 with two versions of bus interfacing: the 
Z-UPC offers the Z-BUS interface found on the Z8000, 
and the Z-UPC/U provides a Z80-compatible interface. 
The Z-BUS interface allows flexible connection to larger 



microprocessor systems and control of distributed I/O 
peripheral functions by means of a multiplexed address 
and data bus. The Z80-bus interface provides easy inter- 
facing with 8 -bit microprocessors and others that employ 
nonmultiplexed address and data buses. 

A logical organization 

The UPC is partitioned into two functional blocks: the 
logic for interfacing with the host-processors, and the 
core microcomputer (Fig. 1). In the multiplexed (Z-BUS) 
version, communication between the host and the UPC 
takes place over the Z-BUS, which provides an 8-bit 
bidirectional address and data port (AD -AD 7 ) and a set 
of control lines (as, DS, RTw, CS, wait). Also, under 
UPC program control, an optional daisy-chain interrupt 
structure— using request (INT), acknowledge (intack), 



HOST CPU INTERFACE 



MICROCOMPUTER 



" INPUT/ 
► OUTPUT 




INTERRUPT 
LOGIC 



1. Microcomputer plus. The Z-UPC universal peripheral controller bases much of its architecture on the Z8 chip, to which it adds circuits at 
left for interfacing with a host processor. Shown is the Z-BUS-compatible version with multiplexed address and data lines. 
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2. File in. Of the UPC's 256-byte register file, 
234 are general-purpose and can function as 
accumulators, buffers, pointers, or stack or 
index registers. The other 22 are specific 
pointers and registers, as well as status and 
control registers for the UPC's I/O facilities. 
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enable input (mi), and enable output (teo) lines— can be 
implemented. The microcomputer portion is based on 
the Z8 microcomputer architecture, whose central pro- 
cessing unit executes instructions averaging 2.2 micro- 
seconds each using a 4-megahertz clock source. The 
CPU's memory comprises 256 bytes of register-file ran- 
dom-access memory (which can be accessed directly by 
the host processor and the UPC), plus 2,048 bytes of 
read-only memory for program storage; other features 
include three I/O ports for device control, two 
timer/counters, and six vectored interrupts. 

In addition to the standard 40-pin version (with 2-K 
bytes of ROM), there are two 64-pin versions of the 
Z-UPC: a ROM-less version and a RAM version, both of 
which have the program address, data, and control lines 
buffered and brought to external pins. The version with 
no program ROM on chip is intended as a development 
tool. The RAM version, which has 36 bytes of vestigial 
bootstrap ROM on chip, is intended as a controller whose 
program is downloaded from the host processor. 

All three of these configurations are available with 
either the nonmultiplexed bus or the multiplexed Z-BUS 
interface to meet the needs of 8-, 16-, or even future 
32-bit systems. 

The UPC processor is organized around a 256-byte 



register file (shown in Fig. 2). Besides storing data and 
control and I/O functions for the processor, the register 
file serves as buffer storage for communication between 
the UPC and the host CPU. 

In addition to 234 general-purpose registers, the regis- 
ter file contains 19 control registers for configuring and 
controlling the Z-UPC's I/O facilities and three parallel 
I/O ports. The control registers both specify how the 
hardware is configured and should function and provide 
status information for it as well. 

A multipurpose register file 

All of the general-purpose registers can function as 
accumulators, data buffers, address pointers, and stack 
or index registers. All ports and control registers can be 
accessed by UPC instructions like any other register. 
Instructions can access the registers directly or indirectly 
with an 8-bit address field. However, a 4-bit addressing 
scheme, which makes use of a register pointer, can save 
memory and execution time. In this scheme the register 
file is divided into 16 register groups, each containing 16 
contiguous locations. The register pointer determines 
which group is being accessed, and a 4-bit address field 
specifies the register within the group. This capability is 
especially useful to speed context switching. 
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3. Control. The 20 control registers in the 
UPC are divided into three groups: 3 for the 
interface status and control; 16 for data, 
status, and control (mapped by the I/O reg- 
ister pointer); and 1 block-access register for 
the transfer of data to or from a buffer file 
that is set up by the UPC. 



Programs running on the UPC may communicate with 
those running on the master processor in a number of 
ways: under interrupt control (either by the UPC or 
master); by transfer of byte data through data, status, 
and command registers; and by transfer of blocks of data 
to and from the UPC's register file. 

Three groups 

The host CPU can directly access the 19 interface 
registers through the Z-BUS interface. As illustrated in 
Fig. 3, the registers are separated from the UPC's inter- 
nal registers and divided into three groups: 

■ Those for interface status and control, which the mas- 
ter processor can access to control UPC-generated Z-BUS 
interrupts, to interrupt the UPC, and to control message 
transfer over the Z-BUS. 

■ Those for data, status, and control, which are mapped 
into 16 registers by the I/O register pointer, controlled by 
the UPC. That arrangement gives the master processor 
direct access to 16 registers and allows transfer of data, 
status information, or control commands between the 
UPC and master processor. 

■ Those for block access, used by the master to transfer 
blocks of data into or out of a buffer in the UPC's register 
file. The UPC has complete control over the placement 
and size of the buffer in its register file. 

Each of the three types can be read or written by the 
master processor. Because the UPC software has com- 
plete control over how these register groups are mapped 
into the register space, the layout of data in the registers 
is independent of the host processor's software and pro- 
tected from it. 

The UPC and the master processor can operate com- 



pletely independently of each other. The UPC can ignore 
the data transfer request from the master by setting a bit 
in its master-processor interrupt control register. Any 
attempt to transfer data from the master when this bit is 
set causes an error flag, which will cause an interrupt to 
the UPC (if interrupts are enabled). 

I/O lines by the dozen 

The UPC has 24 lines dedicated to input and output 
that are grouped into three 8-bit ports. Since the ports 
are mapped into the register file, I/O data can be directly 
manipulated by any instruction. Each port has a mode- 
control register, which allows the port functions to be 
changed during program execution; for example, each 
line of port 1 and port 2 can be individually configured 
as input or output under program control. Each port can 
have its output lines defined as push-pull or as open- 
drain drivers. 

Port 3 is a multifunction port. It has four input and 
four output lines that can lie used for I/O or control 
functions. The control functions available through this 
port include interlocked handshake lines for ports 1 and 
2, interrupt request inputs, timer input and output, and 
Z-BUS interrupt control. 

Timing and counting 

To support timing and counting requirements of soft- 
ware routines, the UPC provides two 14-bit timer/count- 
ers, To and Ti. Among the timer/counter functions that 
are easily implemented by the UPC are; interval delay 
timer, time-of-day clock, watchdog timer (as for refresh- 
ing dynamic memory), external event counting, variable 
pulse-train output, duration measurement for external 
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4. Disk jockey. The UPC makes a controller for a floppy-disk drive that actually stores the file system on chip. The host has only to specify the 
file name and the function to be performed. The 74LS299 shift register converts serial into parallel data, which enters port 1 on the UPC. 



events, and automatic delay after an external event. 

Each timer/counter is divided into a 6-bit prescaler 
and an 8-bit counter and is driven by the internal UPC 
clock, divided by four. The internal clock for Ti may be 
set up for gating or triggering by an external event, or it 
may be replaced by an external clock input. Each 
timer/counter may operate in either a single-pass or a 
continuous mode, so that after the last count either 
counting stops or the counter reloads and continues 
counting. The counter and prescaler registers may be 
altered individually while the timer/counter is running; 
software controls whether the new values are loaded 
immediately or when the end of count (EOC) is reached. 
The two timer/counters may be cascaded using the 
timer-input lines on port 3. 

Interrupting the controller 

To serve host or 1/O-device requests quickly, the UPC 
provides six interrupts from eight different sources: three 
from ports, two from timer/counters, and three from the 
host-processor interface. All six interrupts may be indi- 
vidually or globally disabled. The interrupts are priori- 
tized, with the interrupt-priority control register provid- 
ing 48 different priority schemes for handling concurrent 
interrupts. What's more, the masking and prioritizing of 
the interrupts may be dynamically modified under pro- 
gram control. 

The UPC's interrupts are vectored. When an interrupt 
occurs, the program counter and flags are pushed onto 



the stack, and control passes to one of six predetermined 
interrupt-handling routines. The routine is pointed to by 
an address that has been stored in the first 12 bytes of 
program memory. All of the interrupts are disabled after 
an interrupt is accepted. Interrupts can be nested by 
enabling them during the interrupt service routine; they 
are automatically enabled during the return from the 
routine. 

The Z-UPC instruction set is compatible with the Z8 
microcomputer instruction set (though the UPC's load- 
external-memory instruction is only available in the 64- 
pin RAM version of the Z8). This instruction set, com- 
prising 129 instructions of 43 basic types and using six 
main addressing modes, speeds program execution and 
achieves byte efficiency. The types of data that it allows 
to be used include bits, binary-coded decimal digits, 
bytes, and 16-bit words. 

Z-BUS support 

The UPC can support the full z-BUS interrupt struc- 
ture, including daisy-chained priority resolution and vec- 
tored interrupt acknowledge. Using the interface control 
and status ports, the master processor has the full range 
of Z-BUS mechanisms for enabling or disabling Z-UPC 
interrupts, marking interrupts as being under service, 
clearing interrupts, setting interrupt vectors, and dis- 
abling interrupts from lower-priority devices. 

A program running on the UPC can start the normal 
Z-BUS interrupt sequence (assuming interrupts are 
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enabled) by setting the interrupt-pending bit in its mas- 
ter-processor interrupt-control register. Once that is 
done, the UPC hardware automatically handles the Z-BUS 
interrupt protocol— including output of the interrupt 
vector, which is held in a separate control register. 

The master can generate an interrupt to the UPC by 
setting the end-of-message flag in the master-processor 
interrupt-control port. In addition, UPC interrupts are 
generated from the master when an error condition, such 
as transferring a block of data that is too long, occurs. 

Block transfer within limits 

The UPC's block-access port is ideally matched to the 
block-l/O instructions of the Z8000 microprocessor. 
With a single block-l/O instruction the Z8000 can 
address the block-access port and transfer a string of 
bytes into or out of the UPC. Each access by the Z8000 to 
the block-access port causes a series of actions in the UPC 
involving its data-indirection register and limit-count 
control register. The data-indirection register points to 
the UPC register that is read or written when the master 
reads or writes the block-access port. After each such 
read or write, the data-indirection register is incre- 
mented and the limit-count register decremented. When 
the limit count reaches zero, any further transfers 
through the block-access port will abort and cause a 
length-error interrupt in the UPC. 

Ideas for application 

The intelligence and flexibility of the UPC make it 
suitable for a wide variety of applications and allow it to 
offload the host computer in several ways. The UPC is 
capable of doing intensive off-line calculations, for 
example, such as those for data encryption. Also, it can 
perform the various code conversions and data format- 
ting that are usually required in processor-to-device and 
device-to-device communications. Furthermore, it can 
buffer the data and generate controls for I/O devices 
such as printers and keyboards. 

Figure 4 illustrates the UPC's application as a disk 
controller. Here, a file system can actually be imple- 
mented in the controller itself. The host processor has 
only to specify the file name and the function to be 
performed on the file. Depending on the sector size, 
either the register file or the external RAM in the 64-pin 
RAM yersion can be used as for data buffering. The 
serial-to-parallel conversion is done by a 74LS299 shift 
register, and the data is transferred using handshake 
logic in and out of port 1 . Also, cyclic-redundancy error 
checking can be done by the UPC. 

A UPC software package is available for Zilog's 
PDS8000 development system that includes an assem- 
bler (plz/asm), a linker, and an imager, plz/asm is a 
free-format assembler that generates relocatable and 
absolute object-code modules. It makes provision for 
external symbolic references and global symbol defini- 
tions. Data declarations, control structures, and DO loops 
between them supply a structured approach to the task 
of assembly language programming. 

A development board, similar to the one that is now 
available for the Z8, will also be available. It uses the 
64-pin version of the UPC to prototype a UPC-based 




5. Prototyping. The ROM-less version of the Z-UPC, called a Proto- 
pack, is available in a special 40-pin package with a 24-pin socket on 
its back. Suitable for prototyping and preproduction use, it accepts a 
2716 E-PROM for its first 2-K bytes of program memory. 

system. The code thus developed can later be transferred 
to the ROM in the mask-programmable 40-pin version of 
the UPC, or it can be made available in image form for 
downloading to the RAM version. 

Two serial RS-232-C interfaces will allow the 11- 
by- 14-inch board to be used alone with a cathode-ray- 
tube terminal or to be connected to one of Zilog's PDS or 
ZDS-1 series development systems. Cable connection to 
such a host system will permit the transfer of software 
from the host— where it is developed— to the board for 
testing. Included on the board is a 64-pin Z8, which 
serves as a program monitor for the UPC. 

The board also contains 4-K bytes of 2716 erasable 
programmable ROM (for the monitor/debugger pro- 
gram) and 4-K bytes of 2114 static RAM. For the user 
who wishes to test a ROM-based version of his code, it 
also offers a socket for 4-K bytes of 2716 e-prom that 
may be used in place of the ram. The monitor /debugger 
software, comprising a terminal handler, a debugger, 
command interpreter, and an upload/download handler, 
provides the various commands necessary for control, 
I/O, and debugging. 

A wrapped-wire area of 40 square inches accommo- 
dates additional customer interfaces or special applica- 
tion circuits. This arrangement allows for wide range of 
user applications. 

Aid in prototyping 

The Z-UPC Protopack— the ROM-less version of the 
standard Z-UPC, housed in a pin-compatible 40-pin pack- 
age (Fig. 5) that carries a 24-pin socket to accommodate 
a 2716 E-PROM— is used for prototype development and 
preproduction of mask-programmed UPC-based applica- 
tions. The 24-pin socket is equipped with 12 ROM 
address lines, 8 ROM data lines, and the necessary con- 
trol lines for interfacing with the E-PROM for the first 
2-K bytes of program memory. 

Pin compatibility allows the user to design the printed- 
circuit board for a final 40-pin mask-programmed UPC 
and, at the same time, allows the use of UPC Protopack 
to build prototype and pilot-production units. When the 
final program is established, the user can then switch 
over to the 40-pin mask-programmed UPC for large- 
volume production. The Protopack is also useful in appli- 
cations where masked ROM setup time and mask charges 
are prohibitive and program flexibility is desired. □ 
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Adapting Unix 

to a 16-bit 

microcomputer 

Z-Lab software development system 

with text-processing utilities 

supports 16 users in C language, 

has 32-bit bus for future expansion 



by Bruce Weiner and Douglas Swartz 

Zilog Inc , Cupertino, Calif 



□ In systems based on 16- and 32-bit microprocessors, 
software will account for the bulk of the development 
cost. As more and more logic is squeezed onto a single 
chip, the hardware development process is being simpli- 
fied and its costs reduced. Simultaneously, however, 
more complex and, hence, more expensive software is 
going to be required. 

Zilog's recognition of this trend in computer technolo- 
gy (shown in Fig. 1) led to Zeus, the adaptation of the 
Unix operating system for the Z-Lab 8000 microcom- 
puter [Electronics, Feb. 10, p. 33]. 

Both software and hardware played crucial roles in the 
creation of the Z-Lab development system. Components 
such as the Z8001 microprocessor, the memory/manage- 
ment unit (MMU), and the Z-bus backplane-interface 
(ZBl) bus structure were as critical to the potential of the 
system as was the software itself. Together, the Z-Lab 
and the Zeus operating system foster a software develop- 
ment environment that is a major step toward controlling 
the rapidly escalating software costs of microprocessor 
products. 

Transporting a system 

In selecting an operating system, there were two 
options: writing a new one from scratch or transporting 
an existing one to the Z8001. The decision was made to 
transport one — provided it was possible to find an exist- 
ing operating system that could be adapted quickly and 
was well-suited to software development. 

The search for such an ideal software environment 
ultimately led to the Unix operating system. This system 
was selected for four reasons: it was designed specifically 
for software development and text processing; it had 
already been transported successfully to 16- and 32-bit 
computers; it had a large existing software base with 
applications pertinent to a development environment; 
and it had a large user base. 
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1. Skyrocketing software. As products use more sophisticated 
microprocessors, there is an increase in the amount of engineering 
effort required to write software As hardware costs drop, software 
costs are becoming the major product development expense 
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What is Unix anyway? 



As a general-purpose, multiuser, interactive operating sys- 
tem, Unix offers facilities that are seldom found even on 
larger mainframes. Through its hierarchical file structure, 
any file can be traced back to a single root directory, 
thereby facilitating the management of mass memory In 
addition, peripheral device handlers, files, and interpro- 
cess communications are all compatible with each other, 
simplifying program development. Since one major goal of 
Unix is to increase programmer productivity by providing a 
responsive working environment, Unix includes a vast 
library of utilities ranging from spelling correction routines 
to various compiler compilers and supports over a dozen 
languages, including the language C in which it is written 

However, the most important role of any operating 
system is still managing the mass-storage files in which all 
the programs and data reside Unix imposes no particular 
structure upon the content of these ordinary files Instead, 
it distinguishes between two kinds of special files even 
though they are treated identically by the programmer. 

The first of these is a directory file that simply lists the 
names and vital statistics of other files These other files 
may, in turn, be programs, data, or even other directories. 
This hierarchical structure results in an unusually well- 
organized system in which a file can be specified by its 
path name, which is a sequence of directory names sepa- 
rated by slashes that terminates with the desired file 
name Thus, the same name can be used for files of similar 
function as long as they have different path names. For 
example, /Jones/Statistics and /Smith/Statistics both 
refer to a file named Statistics, but they are not the same 
file because they have different path names indicating 
they are listed in the unique directories Jones and Smith. 

Just as directories are treated in the same manner as 
ordinary files by programmers, so are the second kind of 
special files— input/output calls This distinction is the 



most unusual feature of Unix and one of its greatest 
advantages over other operating systems. These special 
files are read and written just like ordinary ones, except 
that the selected device is activated and the data is 
passed to it using whatever protocol is appropriate Thus, 
programs can send data to, for example, a printer in 
exactly the same way they do to a disk file— except the 
name of the selected output unit is different. 

Unix programs may communicate with each other in the 
same manner as I/O calls The output of one program is 
directed to the input of another while each program thinks 
it is reading or writing a disk file The communication link 
itself is called a pipe and can be created either by the 
program itself or interactively by the programmer In this 
way, a group of related programs may pass data to each 
other in an extremely efficient manner. 

Another feature of Unix is its ability to safeguard original 
programs. Before a program is executed, a fork, or repli- 
cate, operation copies the program, including the code, 
register values, open files, current directory and the like, 
into memory. The replicated process is executed, ensuring 
that the original is never lost or scrambled, in case execu- 
tion does not take place properly. 

Perhaps the most visible portion of Unix is the shell, or 
fundamental control program, which functions as the pri- 
mary interface with the system user. As a command 
language it offers the programmer a productive working 
environment. Multitasking permits programs to be started 
without loss of control of the console Special command 
files may be set up so that any sequence of shell 
commands can be executed by a single user command. 
Commands can even be strung together at the console so 
that the results of one are fed directly to the input parame- 
ters of the next, in the same manner as pipes interfacing 
programs -R. Colin Johnson 



When transported, the Unix operating system was 
enhanced in several ways so that the Z8001 implementa- 
tion might run more reliably. For example, in the stan- 
dard Unix operating system, nothing prevents two users 
from simultaneously modifying a file so that one user 
can accidentally invalidate the other's changes. The 
Zeus operating system qualifies the three standard Unix 
file-opening modes (read, write, and read and write) 
with three access-control modes specifying what other 
users can do with the file. 

The Zeus access control modes are shared, read-only, 
and exclusive. The shared mode, the standard Unix 
control mode, allows other users access to any file they 
desire. In the read-only mode, other users may access the 
file only for read operations. In the exclusive mode, other 
users may not access the file at all; the first user opening 
the file has exclusive access to it until the file is closed. 
Any attempted access to a file that violates these param- 
eters results in a failure of that open operation. 

Other enhancements 

A full-screen text editor, called the visual editor, has 
been implemented in Zeus for cathode-ray-tube termi- 
nals. Its data base contains terminal-control information 
that permits full-screen editing for almost any combina- 



tion of CRT terminals. The terminal data base can be 
updated by the user when adding new terminals to the 
system. 

The editor lets the user display text files one page at a 
time and rapidly move the cursor on that page, inserting 
or deleting characters, words, lines, or groups of lines 
with a minimum number of keystrokes. Several addition- 
al features are available, such as cut-and-paste and 
word-wrap facilities. 

Rebuilding the system 

Another enhancement is the Sysgen program, which 
automatically rebuilds the Zeus system, letting the user 
tailor it to specific requirements. The user can add disk 
and tape drives or other input/output devices using the 
Sysgen program as well. 

Several other utility programs are supplied with Zeus. 
Learn, an interactive program, teaches new users how to 
fully exploit Zeus's facilities; Mail lets users send mes- 
sages to each other in postal format; Calendar automati- 
cally reminds users of events scheduled during the day 
when they sign on and begin using their terminal; Spell 
is a spelling-error detection program that uses a 25,000 
word dictionary; and Man prints selected portions of the 
Zeus reference manual on the user's terminal. Over 
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2. Subdivisions. Zeus separates the memory space for programs 
and data, the latter being subdivided into areas for the stack, 
dynamically allocated variables, and global variables Hardware 
ensures that the stack and dynamic areas do not overlap 

60 other utilities are furnished with the Z-Lab. 

Almost the entire Unix operating system and its appli- 
cation programs are written in C, a system implementa- 
tion language. The key to transporting Unix software is a 
C compiler that generates code for the target system, in 
this case the Z8001 -based Z-Lab 8000. Although C 
carries a certain level of machine independence, this does 
not mean that the entire Unix operating system can be 
transported by merely recompiling it. Most application 
programs, however, can be transported in this manner. 

Seventh edition 

Specifically, the Zeus operating system is Zilog's 
enhanced version of the seventh edition of the Unix 
operating system, which was modified by Bell Laborato- 
ries to eliminate explicit machine dependencies and ease 
its transportation to other computers. Some implicit 
machine dependencies, however, must of necessity 
remain in the Unix kernel. For this reason, transporta- 
tion to Z-Lab is greatly simplified by creating hardware 
very similar to those architectural features implicit in 
this kernel. 

The two major machine dependencies in the Unix 
kernel are the size of integers and pointers and the 
memory management capability required by Unix soft- 
ware. Both the Unix kernel and C assume that integers 
and pointers are the same size and that integer arithme- 
tic can thus be performed on pointers. Examining the 
evolution of the Unix system sheds light on how this 
machine dependency was handled. 

C originally was developed to write Unix, and Unix 
originally was written for Digital Equipment Corp.'s 
PDP-11 family of 16-bit minicomputers. Further, the 
seventh edition of the Unix system was written specifi- 
cally for PDP-11 systems with separate code and data 
address spaces. Thus, microcomputer hardware that pro- 
vides facilities similar to those of a minicomputer such as 



dec's PDP- 11/70 should minimize the transportation 
effort. 

On the basis of this background information, the 
design team decided to run the Z8001 microprocessor in 
the nonsegmented mode for user processes and for 
almost all of the kernel. In a nonsegmented mode, 
programs use 16-bit addresses and are limited to a single 
64-K-byte segment. This means that both integers and 
pointers are considered 16-bit quantities and therefore 
integer arithmetic can be performed on them. 

Because the Z8000 family can support separate code 
and data address spaces, user and system programs may 
have as much memory as a PDP-1 1/70— 128-K bytes, of 
which 64-K bytes are code and 64-K bytes are data. 
Furthermore, the Z8001's 24-bit addressing scheme can 
handle a total system memory as large as 16 megabytes. 
Because the Z-Lab 8000 can handle up to 1.5 megabytes 
of memory the need for swapping programs in and out of 
main memory is reduced, thereby minimizing response 
time when a large number of users are on the system. 

Much of the existing Unix software base takes advan- 
tage of the operating system's dynamic allocation of 
memory. This system characteristic has had a major 
impact on the hardware design of Z-Lab. 

Memory management 

Figure 2 shows how a C program's data is laid out in 
memory. This stack starts at the highest 16-bit data 
address and grows toward lower addresses. Global data 
that is statically allocated starts at address and of 
course does not grow. 

The Unix kernel provides system calls that allow a 
process to dynamically request more data memory. This 
dynamic data area starts just above the global data and 
fills in the unused addresses up to stack. 

Memory space located between the stack and the 
dynamic data area is not necessarily allocated to one or 
the other. The hardware must therefore detect a memory 
reference in the constantly changing gap between the 
two memory areas and make sure they do not overlap. 
When an invalid access is detected, the kernel can either 
allocate more memory or terminate the process, as 
appropriate. 

To protect the memory areas from invalid access, 
Zilog's Z8010 memory management unit was selected 
for the Z-Lab processor board. The MMU relocates 
addresses so that programs can be placed anywhere in 
physical memory and keeps the system from being cor- 
rupted if a user's program runs amok. 

Nonsegmented solution 

If Z-Lab were running in segmented mode, the two 
data areas would be placed in separate data segments, 
and the MMU could detect address violations as well as 
the need for more memory. In a nonsegmented mode, 
however, memory references to both bear the same seg- 
ment number, so detecting a memory reference in the 
gap must be accomplished in another way in order to 
prevent the dynamic data area and the stack from over- 
lapping. 

Although the segmented-mode solution could not be 
used, it did provide the foundation for a nonsegmented 
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3. Multiple MMUs. In the Zeus 
operating system, the Z8001 
processor runs in its nonseg- 
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memory space into separate 
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The break register stops the 
stack and data areas from 
overrunning one another 
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solution, in which the references to the two dynamic data 
areas are made through two different MMUs. In Fig. 3, a 
simplified block diagram of Z-Lab's memory manage- 
ment architecture shows that there are separate MMUs 
for the code, as well as for the stack and data address 
spaces. The MMU select logic determines which one 
should be activated and guarantees that only one will be 
active at any given time. 

The operating system sets the break register, the key 
element in determining whether the stack or the data 
MMU will be activated, pointing to the highest address in 
the dynamic data area. On every data reference to 
memory, address bits 8 through 15 from the Z8001 are 
compared to the value in the break register. Data 
addresses greater than or equal to the break value acti- 
vate the stack MMU; data addresses less than the break 
value activate the data MMU. The MMU selection occurs 
quickly enough for no wait states to be required, even 
with a 6-megahertz Z8001. 

Integrating hardware and software 

The memory management design discussed above 
handles Unix software and nonsegmented Z8000 pro- 
grams. In addition, the memory management architec- 
ture of the Z-Lab processor board can be modified under 
program control to support segmented user and system 
programs. Future software releases can thus take full 
advantage of the 1 6 megabytes of address space provided 
by the segmented Z8001 . 

The Z-Lab development project was approached as an 
integrated product-design effort. A broad-based project 
team was selected to facilitate close cooperation among 
the hardware, software, and mechanical engineers, and 
the memory management architecture thus developed by 
the team solved problems that could not have been 



solved independently by any of the individual groups. 

Likewise, the various goals of the Z-Lab system could 
be attained only with an integrated approach to the 
hardware, software, and mechanical engineering aspects 
of the project. Of these goals, the first was to design a 
Unix-based system with enough flexibility and file- 
system integrity that users could configure and maintain 
it themselves. A second goal was a performance level 
that could comfortably support up to 16 users. The final 
one involved packaging the system for the office environ- 
ment. 

To best achieve these goals, the project team sought a 
system design with minimum power consumption and 
noise levels. Thus, the Z-Lab offers high-performance 
minicomputer power in a quiet and easily portable pack- 
age that consumes only 325 watts. It has no special 
power requirements and no cooling requirements, if 
ambient temperature stays below 40°C. 

Z-Lab system hardware was also designed for expand- 
ability. Using a moderate-sized printed-circuit board 
(approximately 9 by 1 1 inches) kept the hardware con- 
figuration compact while allowing enough board area for 
future Z-Lab products. A highly reliable two-piece con- 
nector, although slightly more expensive than the con- 
ventional one-piece card-edge connector, improved con- 
nection reliability and permitted more connections per 
inch of pc-board edge. 

Bus with a future 

A semisynchronous bus, the ZBI, was chosen for its 
high level of system performance and input/output inter- 
face. All Z8000 peripheral circuits interface with the bus 
simply, needing buffering only to attain the TTL drive 
levels required on the backplane. Z80 peripherals can 
also be attached to the bus by generating the required 
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4. Architectural planning. The Z-Lab development system uses the 
proprietary ZBI 32-bit bus, an error-correcting memory controller that 
communicates with the main memory over a separate high-speed 
bus, and both Winchester disk and cartridge tape controllers 

Z80 timing with simple interface logic. 

The ZBI is a true 32-bit bus with the address and the 
data multiplexed on the same lines (Fig. 4). The band- 
width of the bus (8 megabytes per second) is sufficient 
for future high-speed 32-bit processors and for peripher- 
al controllers as well. 

The Z-Lab error-correcting memory controller (ECC) 
supports 8-, 16-, and 32-bit data transfers, performing 
32-bit error correction with the aid of seven extra syn- 
drome random-access memories that hold the correction 
bits for every 32 data RAMs. The ECC communicates 
with its memory array cards over a very high-speed 
dedicated memory bus. 

Maximizing memory capacity 

All timing and refresh circuitry on the controller is 
centralized, maximizing memory capacity in the system. 
In addition to a maximum of 1.5 megabytes of ECC 
memory in the processor module enclosure, the Z-Lab 



unit has slots for the processor, cartridge tape controller, 
and Winchester disk controller cards as well. 

Two of the Z-Lab's three peripheral controllers are 
intelligent, using Z80B 6-MHz microprocessors. This 
offers three distinct advantages. 

First, device control chores are offloaded from the 
main processor. The operating system thus can commu- 
nicate with the peripheral controllers using high-level 
commands that let the peripheral controllers work in 
parallel with the main processor. For example, Z-Lab 
can issue simultaneous reads or writes to more than one 
disk drive; the disk controller keeps track of head posi- 
tion, sector position, and data transfer. 

Secondly, the intelligent peripheral controllers can 
perform self-diagnostics on power-up or on command, 
thus certifying to the host processor with a high degree 
of certainty that they are functioning correctly before 
processing begins. 

Finally, product maintenance and upgrading is simpli- 
fied by using firmware. As information is gathered on 
how the operating system interacts with the disk under 
different program mixes, the Winchester disk controller 
can be easily "tuned" for higher performance by altering 
the firmware. 

Initial board set 

The Z-Lab board set consists of: 

■ A processor board containing eight serial channels 
with programmable bit-rate, a parallel printer interface 
for either Centronics or Data Products-type printers, a 
memory management subsystem that supports either 
segmented or nonsegmented user processes, and read- 
only memory containing the bootstrap software and pow- 
er-up diagnostics. 

■ An ECC memory controller that supports 32-bit error 
correction for up to 16 256-K-byte memory array cards. 
This board contains detection and reporting logic for 
uncorrectable errors and error-logging logic for correct- 
able errors. 

■ One or more 256-K-byte memory array cards using 
high-speed 16-K dynamic RAMs. 

■ An intelligent cartridge tape controller that handles 
up to four tape drives for file archiving or for backup of 
the entire system. 

■ An intelligent Winchester disk controller that supports 
up to four 24-megabyte 8-in. Winchester disk drives. 

■ An optional serial I/O controller board that supports 
an additional eight serial lines and an additional printer 
port. 

Several other subsystems will be offered with Z-Lab in 
the near future. An expansion chassis will increase the 
number of card slots in the unit from 10 to 20, the 
maximum number a ZBI bus can support, for construct- 
ing very large systems. 

Another offering will be a compatible 40-megabyte 
Winchester drive (40- and 24-megabyte drives can be 
mixed on the system's Winchester controller). Zilog also 
will offer an intelligent serial controller that can perform 
direct-memory-access transfers to and from main memo- 
ry, which will help improve system performance by 
reducing the amount of time that must be spent by the 
processor in servicing terminal interrupts. □ 
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Probing the news 



Software 



Major firms join Unix parade 

Transparent versions of operating system make it available 
for computers ranging from mainframes down to microsystems 



by R. Colin Johnson, Microsystems & Software Editor 



Devotees of Unix, the operating sys- 
tem whose responsiveness has been 
compared to that of a well-tuned 
sports car, are adding to their num- 
ber almost daily. This rapid expan- 
sion of the user base of Unix, devel- 
oped at Bell Laboratories and 
licensed by Western Electric Co., 
has been spurred by the emergence 
of user-transparent versions made 
for computers ranging in size from 
the likes of IBM System 370 main- 
frames down to Z80-based 8-bit 
microcomputer systems. 

Item: Texas Instruments Inc., 
Dallas, long known for its compre- 
hensive software development sys- 
tem, is planning to implement Unix 
through a subcontract with a third- 
party software house. 

Item: Lifeboat Associates, a lead- 
ing 8 -bit software publisher in New 
York, has just signed an exclusive 
marketing contract with Microsoft 
for end-user sales of its 16-bit 
Xenix- 1 1 adaptation for PDP-1 Is. 

Item: Intel Corp.'s Ada compiler 



for the iAPX 432 [Electronics, Feb. 
24, p. 119] is written in Pascal on a 
VAX- 11/780 under Unix. (When 
asked why Unix was used when the 
final compiler release will be under 
VMS, Nicole Allegre, Ada program 
manager for the Santa Clara, Calif., 
company, responds, "The program- 
mers just really wanted to use it.") 

Obeys orders. Those programmers 
at Intel are not alone. Their counter- 
parts across the country have been 
taken by Unix's responsive software- 
development environment. Also, the 
language in which the original Unix 
is written, C, is one of the most 
respected of the structured lan- 
guages extant [Electronics, May 8, 
1980, p. 129]. 

Since Unix was developed on Dig- 
ital Equipment Corp. machines, it 
has been widely used on PDP-11 
minicomputers for some time. How- 
ever, now that Western Electric 
allows systems with only a few users 
to pay a special per-user royalty fee, 
it has become economical for com- 
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mercial software houses to configure 
Unix for even inexpensive systems. 
An increasing number of original- 
equipment manufacturers and com- 
mercial software houses should start 
offering Unix for various other com- 
puter systems. 

Unix is in fact making a strong 
bid to become a standard among 
operating systems for the new wave 
of 16-bit microsystems, though it 
faces stiff competition from the 
entrenched operating system family 
from Digital Research, Pacific 
Grove, Calif. When that company's^ 
16-bit implementation of its MP/M 
becomes available, it will include 
many of the facilities that make 
Unix so desirable— plus CP/NET, 
which allows both 16- and 8-bit 
microsystems to share expensive 
peripherals. OEMs can look forward 
to a rich selection of system-level 
software packages from which to 
choose. Even the 8-bit microsystems 
are acquiring Unix-like capabilities 
without having to sacrifice CP/M 
capability. 

Drawbacks. Unix is not without 
its critics. They say that the system 
cannot be used easily by clerical per- 
sonnel and cite difficult operations, 
like rebuilding the linked list that 
describes the hierarchical file struc- 
ture after a system crash. Some say 
that Unix does not provide adequate 
file-protection systems to make it 
completely trustworthy in commer- 
cial uses. 

Such criticism stems from Unix's 
initial target: cooperative multipro- 
grammer software projects in which 
most of the users were professional 
computer specialists. That is why 
many of the facilities provided by it 
are specifically aimed at efficient 



6-77 



program development. On the other 
hand, Unix is probably best known 
for its document-preparation and 
-management functions, which are 
often used by nonprogrammers. And 
with the addition of a good screen- 
oriented editor, like Zilog's visual 
editor, Unix offers a wide avenue of 
capability for professionals and non- 
programmers alike. 

New version. One of the latest 
Unix versions is the Zeus adaptation 
by Zilog Inc. Cupertino, Calif., for 
its Z-Lab software development sys- 
tem using the Z8000 [Electronics, 
March 24, p. 120]. And to be 
released next month to selected 
OEMs is the Z8000 version called 
Xenix from Microsoft in Bellevue, 
Wash. [Electronics, March 24, 
p. 34]. Among the first of the OEMs 
is Codata of Sunnyvale, which is 
working on a floppy- and hard- 
disk-based microsystem that makes 
use of a Multibus-compatible central 
processing unit. Later this year, the 
8086 version of Xenix is to be deliv- 
ered to Altos Computer Systems of 
Santa Clara for its single-board 
8086-based microsystem. 

After that, Microsoft plans to 
release a 68000 version (as does 
Whitesmiths Ltd. of New York in an 
original implementation), with an 
eye to the iAPX-432 and the 16000 
in an attempt to establish Xenix as 
the standard version of Unix for 16- 
bit microsystems. Not only is Micro- 
soft dedicated to marketing Unix, 
but it is also dedicated to using it: all 



product development programming 
in its Consumer Products division is 
done in C on a PDP- 11/70 under 
Unix and then transported to the 
target microsystem. 

The first computer to which the 
operating system was transferred 
from the one on which it was devel- 
oped was the Interdata 8/32. The 
Wollongon Group of Palo Alto, 
Calif., now offers Unix for the 8/32, 
as well as for the rest of Perkin- 
Elmer's 32-bit minicomputers (Per- 
kin-Elmer having bought Interdata). 

The same. In the Wollongon offer- 
ing, a supreme attempt has been 
made to make this implementation 
virtually identical to the original as 
it appears to the user, in the interest 
of program portability and of pre- 
serving a common command lan- 
guage across Unix systems. 

Unix is also available from Am- 
dahl Corp. for its IBM 370 look- 
alike, the 470 mainframe, and even 
for a computer that is specially opti- 
mized for the C language — the 
C/70 — from BBN Computer Corp. 
[Electronics, Nov. 6, 1980, p. 46]. 
These, like the others, are licensed 
by Western Electric. 

However, before the licensing pro- 
cedures were changed to accommo- 
date small systems, several software 
developers began work on Unix look- 
alikes. These user-transparent, yet 
original, implementation projects are 
now coming to fruition. 

One that has been around for 
more than a year is Whitesmiths' 



Idris [Electronics, March 24, 1981, 
p. 125]. Some of the newer ones are 
aiming at the 8-bit market to main- 
tain compatibility with current soft- 
ware bases. Two, for Z80-based 
microsystems using the S-100 bus, 
come from Morrow Designs of Rich- 
mond, Calif., and Cromemco Inc. of 
Mountain View, Calif., respectively. 

Subtasks. Morrow Designs' ver- 
sion, called /iNIX, runs CP/M as one 
task within its multiuser environ- 
ment, thereby maintaining compati- 
bility with CP/M software while 
gaining the conveniences of a user- 
transparent Unix. The emphasis 
throughout has been on compatibili- 
ty and portability; /jlNIX is written 
entirely in Whitesmiths' C, which is 
not supplied with the package. 
Cromemco's version runs the CDOS 
operating system as a subtask and 
maintains compatibility with that 
already extensive software base, 
including its new C compiler. 

There is even a version, from 
Technical System Consultants Inc., 
for Southwest Technical Products 
Corp.'s 6809-based 128-K-byte mi- 
crosystem. Called Uniflex, it is writ- 
ten entirely in assembly language 
and includes most of Unix's features; 
it supports both floppies and a 20- 
megabyte hard disk. The West 
Lafayette, Ind., firm will add a 
68000 version soon and is looking to 
Ada, Pascal, and C for future high- 
level language projects. □ 
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